True standard Windows app in Python?

[Pjer Holton]

If I were to build a Windows application that is a true standard Windows
application in every conceivable way and that adheres to the MS Windows
standards as much as possible (installation, GUI, printing, registry, RTF
etc.), and if portability to other platforms is only a minor concern, ...
would Python be a good choice?

What packages, libraries and modules would you recommend for GUI,
installation, data storage etc.?

Thank you very much in advance for your advice!

 

[Harald Massa]

Pjer,

I use Python for sth like that.

GUI, printing, registry, RTF

For GUI and Printing I use wxpython

for registry-work I use win32all
rtf is not standardized in any way. It is documented. But you should not
expect the dominating word processor to adhere to this documentation. But
.... it's only text, so it's possible to deal with it.

installation,

Installation: I just create an exe with py2exe and copy the contents of the
distribution directory. To do this in a "Microsoft conformant way" there is
a great bunch of installers availible; some even generate .MSI foramt.
McMillanInstaller provides sth. quite similiar.

 

[Miki Tebeka]

Hello Pjer,

If I were to build a Windows application that is a true standard Windows
application in every conceivable way and that adheres to the MS Windows
standards as much as possible (installation, GUI, printing, registry, RTF
etc.), and if portability to other platforms is only a minor concern, ...
would Python be a good choice?

What packages, libraries and modules would you recommend for GUI,
installation, data storage etc.?

The combination I use at work is:
Python + wxPython + win32all + py2exe + NSIS Installer.

Works like a charm, native looking Windows application in no-time.

HTH.
Miki

 

[Alan Gauld]

If I were to build a Windows application that is a true standard Windows
application in every conceivable way

It depends on what the app does, there are some things you simply
can't do with python in Windows even with winall installed. But
then again there are things you can't do with MFC and C++. It
depends what you are aiming for.

and that adheres to the MS Windows
standards as much as possible (installation, GUI, printing, registry, RTF
etc.),

If you want to get the Windows "kite-mark" then probably Python
is not the best solution, then again if you want to produce it
quickly and cheaply... Pick the tool for the job. Most commercial
apps on Windows are still written in C++ for performance reasons
and because you get access to all the windows stiuff when you
need it. But that comes at a significant price in terms of
effort.

What packages, libraries and modules would you recommend for GUI,
installation, data storage etc.?

If you do go down the Python route I'd recommend either the MFC
stuff in winall, or maybe Qt or wxPython. They all use the native
toolkit/API under the covers.

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Thomas Dorn]

If I were to build a Windows application that is a true standard Windows
application in every conceivable way and that adheres to the MS Windows
standards as much as possible (installation, GUI, printing, registry, RTF
etc.), and if portability to other platforms is only a minor concern, ...
would Python be a good choice?

In your situation (i.e. trying to build a Windows application which
is "standard in every conceivable way"), I would not use Python.

If you do not want to use C++ on Windows, C# (.NET) should be a
good solution for you. You even might have a look at the Python
for .NET solutions (in the near future).

HTHomas

 

[Ville Vainio]

In your situation (i.e. trying to build a Windows application which
is "standard in every conceivable way"), I would not use Python.

Doesn't using the mfc library (like PythonWin does) enable creating
applications that are "standard in every conceivable way"?

 

[Thomas Dorn]

Doesn't using the mfc library (like PythonWin does) enable creating
applications that are "standard in every conceivable way"?

Even if there are wrappers for things like the MFC library, I would
not say that Python is a "good choice" for writing Windows applications
as defined by Pjer (and Pjer was asking whether it Python is a "good
choice" for his kind of projects or not).

I use Python for 80%+ of my projects (mostly cross-platform) and
would normally recommend it for almost any project; but considering
the various Microsoft OS (incl. Longhorn) and their differences, I
think using C#/.NET (or maybe even C++) is a better choice for some-
one in Pjer's situation.

 

[Dave Brueck]

On Sun, 28 Dec 2003 14:28:42 +0100, Pjer Holton

If you want to get the Windows "kite-mark" then probably Python
is not the best solution

Why? Just curious, but what specifically are you thinking of? The OP's question
was pretty vague, so it's hard to tell what the question was really about.

quickly and cheaply... Pick the tool for the job. Most commercial
apps on Windows are still written in C++ for performance reasons

Hmmm... most Windows programs are purely event driven and therefore spend
oodles and oodles of time idle waiting for user input. If in fact most are
still written in C++ I'd say it has more to do with habit and/or tools like
Visual Studio rather than because of performance reasons.

and because you get access to all the windows stiuff when you
need it.

That's what ctypes is for.

-Dave

 

[Dave Brueck]

In your situation (i.e. trying to build a Windows application which
is "standard in every conceivable way"), I would not use Python.

Why?

-Dave

 

[Dave Brueck]

Even if there are wrappers for things like the MFC library, I would
not say that Python is a "good choice" for writing Windows applications
as defined by Pjer (and Pjer was asking whether it Python is a "good
choice" for his kind of projects or not).

Why? I use Python for writing Windows applications all the time (installers,
registry, COM access, etc, etc) and it works really well.

I use Python for 80%+ of my projects (mostly cross-platform) and
would normally recommend it for almost any project; but considering
the various Microsoft OS (incl. Longhorn) and their differences, I
think using C#/.NET (or maybe even C++) is a better choice for some-
one in Pjer's situation.

Can you give a specific example of how the various OSs cause problems for
Python but not for other languages?

-Dave

 

[Alan Gauld]

Doesn't using the mfc library (like PythonWin does) enable creating
applications that are "standard in every conceivable way"?

No, there are several things that you can do using the Win32 API
that you can't do with MFC. Also winall doesn't expose all of MFC
(last time I looked, although it does do the 80%(95%!) that you
need most.

This is especially true when you start to get into controlling
strange peripheral devices etc. MFC is great for standard
business type apps but it is not 100% complete win32 coverage.

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Alan Gauld]

Why? Just curious, but what specifically are you thinking of? The OP's question
was pretty vague, so it's hard to tell what the question was really about.

Well for example writing a fully windows compliant screne saver
is impossible using Python because the MFC classes don;t give
access to all the functions you need. There are lots of non
compliant screen savers out there but they dont get the "fully
compliant" badge...

Hmmm... most Windows programs are purely event driven and therefore spend
oodles and oodles of time idle waiting for user input. If in fact most are
still written in C++ I'd say it has more to do with habit and/or tools like
Visual Studio rather than because of performance reasons.

Consumer magazines persist in benchmatrking performance on things
like search/replace operations etc. You need those benchmark
operations to go full spped to beat the opposituion. Stupid
but a fact of shrinkwrap life...

That's what ctypes is for.

Gives you access to the types but not the low level win32 APIs.
Of course you can write C wrappers for python, but then its no
longer really a Python app.

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Dave Brueck]

Well for example writing a fully windows compliant screne saver
is impossible using Python

You may find this link interesting then.

http://homepage.hispeed.ch/py430/python/index.html

Gives you access to the types but not the low level win32 APIs.

Are you sure you know what ctypes does? What "low level win32 APIs" are you
referring to?

-Dave

 

[Alan Gauld]

You may find this link interesting then.

http://homepage.hispeed.ch/py430/python/index.html

Actually that's pretty darned impressive but from scanning the
code its not fully windows compliant because it doesn't include
the code to cover all the standard corner mouse clicks or
keyboard shortcuts, neither is it plumbed into the GINA(?)
security module so far as I can tell to enable password control.
But OTOH that should be possible...

Now I confess I didn't install it and run it so maybe I'm doing
it an injustice. But certainly when I looked at writing a screen
saver I gave up when I discovered I couldn't even do it using
pure MFC, I had to drop into raw Win32... But I'm a wimp when it
comes to such things ;-)

Are you sure you know what ctypes does? What "low level win32 APIs" are you
referring to?

The win32 API calls that sit below MFC. In particular the device
IO ones for talking to PCI cards and the like.

And you are right I didn't realize all that ctypes could do, I'd
only seen it as a wrapper around the C typesystem - as per the
name! I didn't know, till now, that you could access DLL
functions, so in principle(albeit painfully) you should be able
to access all of the win32 API.

So yes, you could use Python to write a full windows compliant
program, OTOH I'm still not sure that I'd want to write C in
Python!

Alan g.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Dave Brueck]

Actually that's pretty darned impressive but from scanning the
code its not fully windows compliant because it doesn't include
the code to cover all the standard corner mouse clicks or
keyboard shortcuts, neither is it plumbed into the GINA(?)
security module so far as I can tell to enable password control.
But OTOH that should be possible...

Yes - it's most definitely possible. I don't blame the author of that code for
not doing it of course.

The win32 API calls that sit below MFC.

These are very easily accessible via ctypes (I don't use MFC at all).

In particular the device
IO ones for talking to PCI cards and the like.

If they are standard Win32 APIs, then they are accessible. If they aren't
standard Win32 APIs, then they don't fit inside the definition of a "true
standard Windows app" anyway.

And you are right I didn't realize all that ctypes could do, I'd
only seen it as a wrapper around the C typesystem - as per the
name! I didn't know, till now, that you could access DLL
functions, so in principle(albeit painfully) you should be able
to access all of the win32 API.

Not too painfully, actually. The biggest hurdle is creating the Python version
of the structures that get passed around, but that's a one-time hit - after
that it's straightforward.

So yes, you could use Python to write a full windows compliant
program, OTOH I'm still not sure that I'd want to write C in
Python!

Well, I guess that depends. I've been using ctypes almost daily for a year or
so and now I find it annoying to do Win32 programming in C! It's not that
you're writing C in Python as Win32 programming mostly populating structures,
calling functions, and checking error codes - very little of it is actually
language-specific or "normal" C code; rather, it's tedious work in all
languages, so in Python it's nice because you cut out the tediousness of C and
have just the tediousness of Win32 left. ;-)

-Dave

 

[Alan Gauld]

Well, I guess that depends. I've been using ctypes almost daily for a year or
so and now I find it annoying to do Win32 programming in C! It's not that
you're writing C in Python as Win32 programming mostly populating structures,
calling functions, and checking error codes

That's true, I guess I really meant that I don't want to program
Win32, period!

have just the tediousness of Win32 left. ;-)

I'm happy to write slightly non compliant apps using the GUI
toolkits and live a happier life... Even when my job involved
writing "real Windows" stuff I used Delphi rather than C/C++ life
is just too short!


Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[David Bolen]

No, there are several things that you can do using the Win32 API
that you can't do with MFC. Also winall doesn't expose all of MFC
(last time I looked, although it does do the 80%(95%!) that you
need most.

This is especially true when you start to get into controlling
strange peripheral devices etc. MFC is great for standard
business type apps but it is not 100% complete win32 coverage.

This was also addressed in some of the other responses, but I had to
mention that I found it interesting that it would appear that your
past experience yields a perspective that Windows programming is MFC,
with the Win32 API being a really low layer interface. Anything
outside of MFC support is a "strange peripheral device"?

From my perspective, MFC is a particular high level GUI package that
you might or might not use, but the Win32 API is definitely the way to
program for Windows. I've rarely ended up using MFC (and never since
moving to Python/wxPython), but I did and still do use the Win32 API
all of the time (whether from Python or other languages). True, Win32
is lower level than MFC, but to me, it's the normal level, rather than
a low level (low level on Windows would be the kernel or device driver
interfaces).

And since I can get to the Win32 API in general (even if not wrapped
with win32all, there's the older calldll and the newer ctypes), I
always figured there was very little that that Python couldn't do
under Windows if I needed it. But again, that's thinking of the Win32
API and ignoring MFC entirely.

Anyway, I just found it interesting how past experience (and the sorts
of apps we've probably worked on) can bias a viewpoint to what it
means to program for a specific system.

For the obligatory in-context comment, for me, I cover true standard
Windows apps with Python+wxPython+installer+InnoSetup.

-- David