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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4