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
sys.vm(id='cpython', name='CPython', platform='C',
usersitesuffix='python26') # on win32: Python2.6
sys.vm
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.
Agrred.
-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.)
Michael
--
http://www.ironpythoninaction.com/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
