[Python-Dev] Second draft: PEP397: Python launcher for Windows (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Thu Mar 24 15:21:48 CET 2011

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

More information about the Python-Dev mailing list