[Python-Dev] PEP about sys.implementation and implementation specific user site directory

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