[Python-Dev] Second draft: PEP397: Python launcher for Windows

[Michael Foord]

On 23/03/2011 01:30, Mark Hammond wrote:
> On 23/03/2011 6:12 AM, Michael Foord wrote:
>> On 22/03/2011 07:21, Mark Hammond wrote:
>>> Hi all,
>>> I've made some changes to the draft PEP and checked it into the PEP
>>> repository as PEP397. The reference implementation is currently being
>>> tracked at http://bugs.python.org/issue11629.
>>>
>>
>> Hey Mark,
>>
>> One way of supporting alternative implementations (that may not even
>> have a standard install directory) is allowing configuration. e.g.
>> config.ini
>>
>> [paths]
>> ironpython = c:\Program Files\IronPython 2.7\ipy.exe
>> ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
>> jython = c:\Users\foobar\jython2.5\jython.exe
>
> Hi Michael,
>
> I'd have no problem with that in general, but how would you feel about 
> letting the PEP stand as it is without this additional requirement and 
> then treat this as an additional feature to be thrashed out 
> separately?  I intentionally worded the PEP to specifically allow 
> these kinds of features to be added outside the PEP process.
>
> For example, I guess the name of the INI file wouldn't be config.ini, 
> and I guess there might need to be a strategy to allow it to exist in 
> multiple places for when users want this feature but don't have write 
> access to the location of py.exe.  Then people might want it to be in 
> the cwd, or in any parent of the cwd, etc... Further, it might also be 
> possible to support this with simple environment variables which might 
> wind up being just as (or more) reasonable (the concept of per-user 
> environment variables already exist and a UI already exists for 
> editing them, and it would allow different cmd-prompts to have 
> different "rules" with minimal complexity) - not that I am necessarily 
> advocating this - I'd just prefer the PEP to not get bogged down with 
> those kinds of issues.
>

Well... I'd rather see the pep implemented as is than not implemented. 
On the other hand I think it would be a great shame for it to be 
implemented in a way that excludes-until-someone-else-fixes-it the other 
implementations. (i.e. I think built-in support for other 
implementations would be vastly preferable.) It's your PEP though, and 
I'm still +1 on the idea.

I'm not married to it being a config file - registry entries would be 
fine (implementations could modify their installers or ship scripts to 
create the correct entries). I'm not sure about environment variables, I 
suppose it would be ok - but modifying a single environment variable 
with multiple paths / interpreters could get icky.

All the best,

Michael

> Cheers,
>
> Mark


-- 
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html