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

Mark Hammond skippy.hammond at gmail.com
Fri Jul 1 04:21:54 CEST 2011

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

More information about the Python-Dev mailing list