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

[Mark Hammond]

On 30/06/2011 10:09 PM, Vinay Sajip wrote:
> 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.

This is just clumsy wording on my part - what I'm trying to say is 
simply that 'vpython3' will not match a customized command 'vpython'.

> 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?

The idea is that a user without admin permissions can customize the 
behaviour - so the admin can add a .ini file, but the user can override 
any commands in that file with their own definitions.

> 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.

The idea is that some users will not have permission to edit the one 
next to the launcher.  I'd be open to considering this yagni if others 
agree.

 > 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.

The intention is that there only be a single launcher, as only one app 
can be associated with .py files.  OTOH though, file associations can be 
configured per-user IIRC, and assuming that is the case, we could avoid 
my multiple-ini-file usecase above by just allowing a different launcher 
to be registered for a specific user.  This is sounding difficult from 
the UI perspective though (ie, does the installer then need to ask that 
question, will there be a post-install technique for per-user 
registration, etc?)

> 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?

I came at this from the other angle under the assumption there will only 
be one launcher installed - so common things can be stored in the 
launcher-adjacent file and per-user special cases can be in the per-user 
APPDATA dir.

If the expectation was multiple launchers be installed, then I'd 
probably then prefer to KISS and only have the launcher-adjacent file 
supported at all.

>
> 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.

Sure, that would be awesome!  I think that will mean your impl is fairly 
close to the first draft of the PEP I checked into HG, which is nice and 
still quite useful to use :)

Thanks!

Mark