[Python-Dev] PEP 370 and IronPython
fuzzyman at voidspace.org.uk
Fri Oct 9 13:53:57 CEST 2009
M.-A. Lemburg wrote:
> Christian Heimes wrote:
>> Nick Coghlan wrote:
>>> Importing yet-another-module for use in site.py doesn't sound like a
>>> great idea, so it may make sense to migrate that information into the
>>> sys module is this approach is taken. "sys.name" is a little generic
>>> though - something more explicit like "sys.vm" would be better.
>> The platform modules uses additional modules like the re module. On my
>> system "import platform" loads 7 additional module. The platform modul
>> also uses multiple function calls and regular expression to detect the
>> vm. I'm not going to blame the author of the function for the way the
>> feature is implemented. It's the best way and I'd probably done it the
>> same way, too. But it's an unnecessary slow down of every interpreter
>> startup. 'sys.vm' it is.
>>> Implementation specific user directories sound like a good idea indeed.
>>> An alternative to a lookup table approach might be to be a little more
>>> direct and just retrieve the final part of the user specific directory
>>> name directly from a new function in the sys module. Then different VM
>>> authors can choose any directory name they want without CPython's
>>> site.py needing to know anything else about them.
>> I like your idea. It might be a better idea to turn sys.vm into a struct
>> like sys.float_info. The struct can contains a set of required
>> attributes like an id, a capitalized name, the platform (C, .NET, Java)
>> and the suffix for the user site directory.
>> sys.vm(id='cpython', name='CPython', platform='C',
>> usersitesuffix='python26') # on win32: Python2.6
>> sys.vm(id='ironpython', name='IronPython', platform='.NET',
>> usersitesuffix='ironpython26) # on win32: IronPython2.6
> +1 on adding something like this, though, I'd use
> sys.python_implementation or just sys.implementation
> since not all Python implementations are virtual machines -
> many compile to machine code or some intermediate format.
> -1 on importing platform in site.py. Python's startup time is not
> great to begin with and this would cause the load time to increase
> even more.
Agrred. (And import time is even worse on IronPython.)
More information about the Python-Dev