[Python-Dev] Python for windows.

Mark Hammond mhammond at skippinet.com.au
Wed Nov 26 23:51:58 CET 2008

> > But these are written with applications in mind - Python isn't an
> > application - its used to *write* applications.  I don't see a good
> reason
> > to support these guidelines.  I do see a reason to help support
> people
> > ensure their Python implemented applications can meet the guidelines,
> but
> > I'd never advise such people to install the python.org installer and
> have
> > their application use Python from that directory.
> I disagree. While it might not be really necessary for HP to have
> Python
> comply to a formal test suite, I'm sure other users do need to pass
> these test suites for whatever reason, and they are unhappy if they
> don't pass out of the box.

IIUC, the test suite is about having the Python installer certified as "OEM
Ready", which means a few special things - including, IIUC, the "right" to
be installed in a new PC.  My broader point is that I would advise against
any application vendor reusing the standard Python installer for their
application, as it exposes the ability for the user to remove it, thereby
breaking the application.  I would recommend that the application vendor
take full control of the Python they rely on and install a "private" copy
(either in their own directory or in a directory named other than "Python

In other words, I'm all for helping application vendors in every way to have
their installers meet such guidelines, but I see having the Python installer
itself meet such guidelines as effectively pointless as no one would
actually need it.

Obviously I'm wrong here though - HP obviously *is* wanting to install it as
is, and doesn't mind that the user could accidently break their scripts.
I'm very surprised by that, but I have to accept it :)  On the other hand,
I'd really like to ensure they understand the risks and for me to understand
why those risks are acceptable...

> > Ditto for python.exe etc - its impossible to add a reasonable
> manifest, as
> > the manifest requirements would depend entirely on what the python
> program
> > itself does.  There is no way python.exe can know what it will be
> asked to
> > do.
> FWIW, python.exe *does* have a manifest. The manifest is primarily
> about static linking. I don't know what other uses a manifest may have,

The issue is regarding the Vista "user access control" flags, but yes, I see
that python.exe does include a UAC entry in its manifest.  As I mentioned,
it will obviously not be approriate for all Python apps, but it is there and
that is what matters for this discussion.

> Can you please elaborate? What specific elements of the manifest are
> you thinking of that are not universally correct for python.exe?

A specific Python script may need a different UAC flag to work correctly in
all cases - specifically one that requires elevation.  If the manifest was
appropriate for that script Windows would automatically elevate, but as
things stand, the user would need to manually elevate before executing that

> Perhaps. I wouldn't go so far, though. It's surely puzzling if a system
> comes with a pre-installed Python, but if that Python actually works,
> I don't think that does much damage.

Agreed.  I'm just surprised app authors are willing to take the risk this
implies.  I still occasionally get email from people (presumably via my
email addy which used to be in Pythonwin) saying "I've got this Python thing
installed on my PC - is it a virus?  Can I remove it?".  I tend to say "it’s
a programming language - if you don't know you need it, you probably don't,
so sure, uninstall it". 

> Of course, anybody embedding
> Python
> *should* integrate it into his own application and installation
> procedure. If we really want this guideline to be followed, we should
> document explicitly how one does that (and no, pointing people to
> py2exe is not sufficient).

Actually, I don't think its that hard.  Just plonk what you need (or
*everything* except what you know you don't need, eg docs) in the same
directory structure, test, rinse and repeat.  Ideally you would also tweak
the resource in pythonxx.dll which tells it the registry key to use too.  If
you had special UAC requirements you might even make a copy of python.exe
which is identical except for the manifest, but now we are starting to get
into app specific requirements...



More information about the Python-Dev mailing list