[Python-Dev] PEP about sys.implementation and implementation specific user site directory (original) (raw)

Scott Dial scott+python-dev at scottdial.com
Mon Oct 12 11:38:56 CEST 2009

Christian Heimes wrote:

id (required): lower case identifier, for example "cpython", "ironpython", "jython", "pypy"

name (required): mixed case name of the implementation, for example "CPython", "IronPython", "Jython", "PyPy"

Why both? Is it not true that the following is guaranteed?

sys.implementation.id == sys.implementation.name.lower()

Furthermore, why is a lower-case-only constant superior to a mixed-case identifier? I wonder this especially given that platform.python_implementation() already returns mixed-case constants.

Why not include the version of the language?

platform (required): platform or language of the implementation, for example "C", ".NET", "Java"

What should someone like PyPy say here? Do you have a use-case in mind? What is the relevance of this field?

runtime (required): lower case runtime library of the implementation, for example "libc", "msvcrt90", "java6", ".net"

Same questions as above. Is the java-runtime not dependent on libc?

$ ldd /opt/sun-jdk-1.6.0.15/jre/bin/java | grep libc libc.so.6 => /lib/libc.so.6 (0xb7d70000)

compiler (required): verbose name of the compiler, for example "GCC 4.3.3", "Java HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1"

I think other commenters have already asked what exactly is considered the "compiler"? This is especially interesting if you consider PyPy, as well. What is the item being compiled that you are interested in? What is the use-case for this info? It could vary based on module: some modules could've been built with a different compiled or even compiled to bytecode by a different implementation or etc.

It seems like (platform, runtime, compiler) are guesses at what might be useful. But, in the absence of use-cases they are not useful, perhaps misguided, and create a maintenance burden for the future. A lot of this info is available via the platform module. And the only reason given to not use the platform module was to avoid adding dependencies for site.py. I don't see that as an open invitation to adding other fields that are already available via the platform module. Until they are critical to run-time performance, why not wait to add these extra things?

The only thing that has been indicated as needed is the identifier for the python implementation. sys.vm or sys.implementation may very well fully support the use cases given merely by being a string.

-- Scott Dial scott at scottdial.com scodial at cs.indiana.edu

More information about the Python-Dev mailing list