[Python-Dev] PEP 397 (Python launcher for Windows) reference implementation

Vinay Sajip vinay_sajip at yahoo.co.uk
Thu Jun 30 14:09:43 CEST 2011

Mark Hammond <skippy.hammond <at> gmail.com> writes:

> Not yet - my last update of the PEP has made the existing reference 
> implementation out-of-date, so I want to work on that before starting on 
> the C version.  However, seeing as my note about the most recent PEP 
> update attracted zero comments, I admit I lost any sense of urgency on 
> actually doing this...  I'll make an effort to update that reference 
> impl in the next week or so (but obviously anyone else is free to help ;)

Sorry, I just recently came across the PEP when Tim Golden pointed it out to
me, when I asked a question about executable script support in packaging. I
think I was probably not so focused on Windows at the time of the original
announcement ...

There's a lot to like in the PEP, and I have some questions relating to the
latest version:

1. In the section on shebang line parsing, it says "If the command starts with
the definition of a customized command followed by a space character, the
customized command will be used." Sorry if I'm being dense, but what's the
significance of the trailing space character? In fact, your vpython example in
the customeised comments section doesn't show a trailing space - you've used
'#! vpython' as the shebang line.

2. The section on .ini files says that "Commands specified in the [.ini file
in the] "application directory" [APPDATA] will have precedence over the one
next to the [launcher] executable." What's the benefit of this? If you have
only one launcher executable of one type (say console, 32-bit) on a system,
then there's no point in having two locations for .ini files. If you have
multiple copies of the launcher and multiple .ini files next to them, then
with this precedence order, you can't specialise the behaviour of anything in
a specific launcher .ini that's also specified in the APPDATA .ini. Doesn't it
make more sense to look for a setting in any file next to the launcher, and if
not found there, look in the APPDATA? That way common things can be defined in
the APPDATA .ini and overridden for special cases in the launcher-adjacent
.ini. Or have I got completely the wrong end of the stick?

By the way, I've already converted the existing Python reference implementation
to C (I did it before I saw your response to my post). It basically works in
that it does what the Python version does, but doesn't include any handling of
-32 suffixes or .ini files. I can post this on BitBucket if anyone's interested,
but it's a work in progress. I'm working on some simple tests.


Vinay Sajip

More information about the Python-Dev mailing list