report at bugs
Apr 26, 2012, 2:08 PM
Post #9 of 12
Eric Snow <ericsnowcurrently [at] gmail> added the comment:
Thanks for bringing this up, Martin.
sys.implementation is about having an implementation-specific location (hence sys) to consolidate explicit values concerning the implementation. It's partly about clarifying the run-time distinction between Python-the-language and Python-the-implementation.
'name' and 'version' are the initial fields in sys.implementation because they are the most obvious choices, and a good starting point. If sys.implementation were available now we'd use it in importlib. That's what has motivated me to pursue this.
You are correct that we can hard-code "cpython" in the bootstrap code to generate the cache tag. And perhaps that would be a better use of time. We can't just use platform.python_implementation(), however, since the frozen importlib can only use builtin modules.
I expect you're right that some of the importlib code (particularly w.r.t. cached modules) is CPython-specific. However, I'm sure Brett has tried to minimize that subset of the module. Maybe he knows if the other implementations have plans for using importlib or how it affects them. If not, I'll ask around.
Regardless, importlib is not the only motivator here. Right now platform.python_implementation() has to guess the implementation name. Having the different implementations specify the name explicitly in the sys module would be an improvement without a lot of work. Nick Coghlan has indicated that it would be useful for the test suite.
Ultimately, sys.implementation would become the source for information about a specific Python implementation. Others could expound the point better, but as time goes by this will be more important. This current effort would get the ball rolling. Consequent to the concerns so far, I'll try to get a PEP out in the next couple days.
Python tracker <report [at] bugs>
Python-bugs-list mailing list