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

[Michael Foord]

On 24/03/2011 03:02, Mark Hammond wrote:
> On 24/03/2011 1:20 PM, Michael Foord wrote:
>> On 24/03/2011 00:44, Dj Gilcrease wrote:
>>> On Wed, Mar 23, 2011 at 8:14 PM, Mark
>>> Hammond<mhammond at skippinet.com.au> wrote:
>>>> If you guys (or anyone) would like to agree on some precise rules for
>>>> both
>>>> the location of the config file and its contents and express this as
>>>> a patch
>>>> to the PEP text, I have no problem supporting it in the 
>>>> implementations.
>>>> I'd like to insist that the format of the config file was such that 
>>>> the
>>>> GetPrivateProfileString() Windows function could be used to extract
>>>> the data
>>>> (eg, only '=' can be used to separate the name/value pair,
>>>> case-insensitive
>>>> and no support for string interpolation) as I have no interest in
>>>> writing my
>>>> own config file parser in C :)
>>> In the user directory much like TortoiseHG adds a murcurial.ini file
>>> to the users directory for basic globa config the launch could look
>>> for a python.ini there and use to to add known paths or version
>>> overrides on a user by user basis.
>>
>> A single global location (for shared installs) or a single per-user
>> location for per-user installs would seem to be sensible if the config
>> file route is chosen.
>
> My concern with that would be that an administrator may install 
> Python, but the user may not have write access to that global 
> location, leaving that user unable to customize the launcher.  OTOH, 
> that is how things work on Unix today - such users could not change 
> what /usr/bin/python points to).  Always using a per-user location 
> would mean there is no opportunity to have global settings, but it is 
> unclear which is the lesser of 2 evils.  Supporting both might even be 
> reasonable if the rules are very straightforward.
>

I would look first for a local config and fallback to a global config. 
That way you can choose your evil... With a single config location for 
each it should be simple enough.

> I'd still very much like to see the change to the wording of the PEP 
> to describe this feature though, otherwise I fear different people 
> will have different assumptions about exactly what it does and how it 
> does it...
>

I can provide a suggested pep wording if you like.

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