PEP about sys.implementation and implementation specific user site directory
Fellow Python developers! In the light of our recent discussion about implementation specific information and user site directory I like to start a new PEP. Much to my regret I wasn't able to contribute to Python core development over the past months. I hope I can find some free time over the next weeks. Before I start with the PEP I like to reach consensus over the goal. Alternative implementations of our beloved programming languages are becoming more important every day. Although IronPython, Jython and PyPy are trying hard to get as compatible to CPython as possible there are numerous reasons for conditional code. General Python unit tests vs. CPython specific unit tests are one reasons, implementation specific module search paths are another. At the moment Python has no easy way to inspect the implementation besides some code in the platform module. I'm proposing two new attributes in the sys module: sys.implementation and sys.userdirsuffix. sys.implementation ------------------ (Proposed by Nick, MAL and others.) sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation. Implementations may choose to add additional fields as they see fit. Some fields like compiler are useful for introspection and are already part of sys.version. I like to include them for the sake of completeness. 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" platform (required): platform or language of the implementation, for example "C", ".NET", "Java" runtime (required): lower case runtime library of the implementation, for example "libc", "msvcrt90", "java6", ".net" 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" ... sys.userdirsuffix ----------------- sys.userdirsuffix is an implementation and platform specific string that is used to construct the path for the user site directory as explained in PEP 370. The string contains the implementation name as well as the version number of Python. Examples: python2.6 (CPython, Unix) Python26 (CPython, Windows) ironpython2.6 (IronPython, Unix) IronPython26 (IronPython, Windows) ... Comments? Christian
Christian wrote:
sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation. Implementations may choose to add additional fields as they see fit. Some fields like compiler are useful for introspection and are already part of sys.version. I like to include them for the sake of completeness.
Given that this is all about establishing some common ground between implementations I would propose not using a CPython specific term here such as PyStructSequence :) The Python docs seem to use structseq for sys.float_info.
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"
What's the value of this attribute? The main reason I ask is there's no way that I know of to determine the JIT being used in .NET. We could of course fill in some dummy value here for IronPython but I'm also not sure why anyone would use this. Otherwise it looks good to me.
Given that this is all about establishing some common ground between implementations I would propose not using a CPython specific term here such as PyStructSequence :) The Python docs seem to use structseq for sys.float_info.
Also, why does it have to be a sequence in the first place? Wouldn't a plain object with named attributes be good enough?
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"
What's the value of this attribute? The main reason I ask is there's no way that I know of to determine the JIT being used in .NET. We could of course fill in some dummy value here for IronPython but I'm also not sure why anyone would use this.
Also, why is it the name of the JIT compiler, and not the name of the source language compiler? Regards, Martin
Martin v. Löwis wrote:
Given that this is all about establishing some common ground between implementations I would propose not using a CPython specific term here such as PyStructSequence :) The Python docs seem to use structseq for sys.float_info.
Also, why does it have to be a sequence in the first place? Wouldn't a plain object with named attributes be good enough?
Any object with attributes is good enough. For CPython a structseq provides the necessary feature of a read only object with attributes. I figured out it's the easiest way to archive the goal without creating a new class.
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" What's the value of this attribute? The main reason I ask is there's no way that I know of to determine the JIT being used in .NET. We could of course fill in some dummy value here for IronPython but I'm also not sure why anyone would use this.
Also, why is it the name of the JIT compiler, and not the name of the source language compiler?
The term "source language compiler" describes the intent of the field perfectly. Thanks Martin! I was merely guessing what the compiler name may look like on Jython. Christian
Also, why is it the name of the JIT compiler, and not the name of the source language compiler? From the Jython side it is easier to get the VM name compared to the
On Fri, Oct 9, 2009 at 8:34 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote: source language compiler. Although there is a property on java.lang.System called "java.compiler" it is often empty. -Frank
Dino Viehland wrote:
Given that this is all about establishing some common ground between implementations I would propose not using a CPython specific term here such as PyStructSequence :) The Python docs seem to use structseq for sys.float_info.
You got me! :)
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"
What's the value of this attribute? The main reason I ask is there's no way that I know of to determine the JIT being used in .NET. We could of course fill in some dummy value here for IronPython but I'm also not sure why anyone would use this.
Martin has already answered both points to my satisfaction. Do you agree with him? Christian
2009/10/9 Christian Heimes <lists@cheimes.de>:
Fellow Python developers!
In the light of our recent discussion about implementation specific information and user site directory I like to start a new PEP. Much to my regret I wasn't able to contribute to Python core development over the past months. I hope I can find some free time over the next weeks.
Glad to have you back!
Before I start with the PEP I like to reach consensus over the goal. Alternative implementations of our beloved programming languages are becoming more important every day. Although IronPython, Jython and PyPy are trying hard to get as compatible to CPython as possible there are numerous reasons for conditional code. General Python unit tests vs. CPython specific unit tests are one reasons, implementation specific module search paths are another. At the moment Python has no easy way to inspect the implementation besides some code in the platform module.
I'm proposing two new attributes in the sys module: sys.implementation and sys.userdirsuffix.
Overall, +1.
sys.implementation ------------------
(Proposed by Nick, MAL and others.)
sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation. Implementations may choose to add additional fields as they see fit. Some fields like compiler are useful for introspection and are already part of sys.version. I like to include them for the sake of completeness.
Can we generate sys.version from sys.implementation then?
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"
platform (required): platform or language of the implementation, for example "C", ".NET", "Java"
runtime (required): lower case runtime library of the implementation, for example "libc", "msvcrt90", "java6", ".net"
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"
...
sys.userdirsuffix -----------------
Why not site.userdirsuffix? -- Regards, Benjamin
Benjamin Peterson wrote:
sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation. Implementations may choose to add additional fields as they see fit. Some fields like compiler are useful for introspection and are already part of sys.version. I like to include them for the sake of completeness.
Can we generate sys.version from sys.implementation then?
sys.version is created by Py_GetVersion() which uses Py_GetCompiler() for the compiler information: PyOS_snprintf(version, sizeof(version), "%.80s (%.80s) %.80s", PY_VERSION, Py_GetBuildInfo(), Py_GetCompiler()); For CPython the compiler attribute should be set to the return value of Py_GetCompiler().
sys.userdirsuffix -----------------
Why not site.userdirsuffix?
Because all implementations of Python like to use the same, unpatched site module. The sys module is different for every implementation. It's more convenient to have an attribute on the sys module that can be filled by each implementation. I could also add a lookup table for all known implementations to the site module. But what about unknown or new implementations? They would have to wait until we add a new entry for them. The sys.userdirsuffix is more flexible and future prove. Christian
2009/10/9 Christian Heimes <lists@cheimes.de>:
Benjamin Peterson wrote:
sys.userdirsuffix -----------------
Why not site.userdirsuffix?
Because all implementations of Python like to use the same, unpatched site module. The sys module is different for every implementation. It's more convenient to have an attribute on the sys module that can be filled by each implementation. I could also add a lookup table for all known implementations to the site module. But what about unknown or new implementations? They would have to wait until we add a new entry for them. The sys.userdirsuffix is more flexible and future prove.
I think we should make a semi-private (public to the stdlib) module like _sys or _implementation part of the Python VM API. Then, instead of stuffing everything into sys, we can provide this information in modules where it belongs. -- Regards, Benjamin
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module like _sys or _implementation part of the Python VM API. Then, instead of stuffing everything into sys, we can provide this information in modules where it belongs.
That's an interesting counter proposal. Your idea requires an additional import that I try to avoid. Looking at memory and performance, an additional module that is imported anyway isn't better. In my humble opinion the implementation information belongs into the sys module anyway. A new module just for the user site suffix seems unnecessary. Christian
2009/10/9 Christian Heimes <lists@cheimes.de>:
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module like _sys or _implementation part of the Python VM API. Then, instead of stuffing everything into sys, we can provide this information in modules where it belongs.
That's an interesting counter proposal. Your idea requires an additional import that I try to avoid. Looking at memory and performance, an additional module that is imported anyway isn't better. In my humble opinion the implementation information belongs into the sys module anyway. A new module just for the user site suffix seems unnecessary.
But we want to hide that this is an implementation detail from the user. Having a new module just for this attribute might seem like overkill, but I hope that we could use it for more things in the future. Besides, if _sys is a builtin module, importing it will not add much overhead. I forgot to ask before: Does this deprecate platform.python_implementation()? -- Regards, Benjamin
On Fri, Oct 9, 2009 at 18:14, Benjamin Peterson <benjamin@python.org> wrote:
2009/10/9 Christian Heimes <lists@cheimes.de>:
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module like _sys or _implementation part of the Python VM API. Then, instead of stuffing everything into sys, we can provide this information in modules where it belongs.
That's an interesting counter proposal. Your idea requires an additional import that I try to avoid. Looking at memory and performance, an additional module that is imported anyway isn't better. In my humble opinion the implementation information belongs into the sys module anyway. A new module just for the user site suffix seems unnecessary.
But we want to hide that this is an implementation detail from the user. Having a new module just for this attribute might seem like overkill, but I hope that we could use it for more things in the future.
To also address Christian's import worry, this new module could contain everything needed to start the interpreter, much like _warnings does compared to warnings. But I honestly don't see why this doesn't belong in sys; it has to do with the system environment which is the interpreter. Yes, some things currently in sys could possibly be put elsewhere (e.g. the exception stuff could be in 'exceptions'), but I don't think sys is that much of an odd collection of code. Without having a desire to eventually clean up the sys module (which I am not proposing as I know that will never fly) I don't see this as being worth it.
Besides, if _sys is a builtin module, importing it will not add much overhead.
Well, that's assuming the other interpreters makes it built-in. Otherwise it's only a CPython/python.org perk.
I forgot to ask before: Does this deprecate platform.python_implementation()?
Probably should. -Brett
2009/10/9 Brett Cannon <brett@python.org>:
But I honestly don't see why this doesn't belong in sys; it has to do with the system environment which is the interpreter. Yes, some things currently in sys could possibly be put elsewhere (e.g. the exception stuff could be in 'exceptions'), but I don't think sys is that much of an odd collection of code. Without having a desire to eventually clean up the sys module (which I am not proposing as I know that will never fly) I don't see this as being worth it.
That doesn't mean we have to make it more dirty. usersiteprefix is used exclusively by site.py to load user modules; it has no function in the interpreter core.
Besides, if _sys is a builtin module, importing it will not add much overhead.
Well, that's assuming the other interpreters makes it built-in. Otherwise it's only a CPython/python.org perk.
As far as I am aware, all current Python implementations can build in modules. -- Regards, Benjamin
Benjamin Peterson wrote:
I forgot to ask before: Does this deprecate platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python versions and as such not really suitable for such deprecations. It'll also take a long while before all Python implementations expose a new sys module attribute along the proposed lines. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 10 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
M.-A. Lemburg wrote:
Benjamin Peterson wrote:
I forgot to ask before: Does this deprecate platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python versions and as such not really suitable for such deprecations.
It'll also take a long while before all Python implementations expose a new sys module attribute along the proposed lines.
However, the function could be updated to take advantage of the new sys.implementation attribute when it was available. If it didn't find it, it would fallback to figuring out the way it does now. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
M.-A. Lemburg wrote:
Benjamin Peterson wrote:
I forgot to ask before: Does this deprecate platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python versions and as such not really suitable for such deprecations.
It'll also take a long while before all Python implementations expose a new sys module attribute along the proposed lines.
However, the function could be updated to take advantage of the new sys.implementation attribute when it was available. If it didn't find it, it would fallback to figuring out the way it does now.
Sure. It already does that for a couple of other APIs. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 11 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation.
I think it is important to confirm in advance that all the implementations listed below agree to implement the PEP "soonish" after it's adopted. "Required" sounds like a strong term - however, if an implementation chooses not to implement the PEP, it can do whatever it wants, including omission of required fields.
id (required): lower case identifier, for example "cpython", "ironpython", "jython", "pypy"
Doing some bike-shedding: I'd like to not use "cpython" as the name of the python.org implementation. This term, I believe, was coined around JPython, somehow making the implementation language the primary means of distinction. However, there may be alternative implementations written in C (e.g. unladen swallow), or otherwise be "C based" (e.g. pypy). So I propose that the python.org version is identified as "python".
name (required): mixed case name of the implementation, for example "CPython", "IronPython", "Jython", "PyPy"
Likewise; alternatively "python.org". Regards, Martin
Martin v. Löwis wrote:
So I propose that the python.org version is identified as "python".
But then we won't have a generic term for the language itself, independent of any implementation. The "c" in cpython doesn't necessarily have to refer to the implementation language. Maybe it stands for "classic python". :-) -- Greg
Martin v. Löwis wrote:
sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation.
I think it is important to confirm in advance that all the implementations listed below agree to implement the PEP "soonish" after it's adopted. "Required" sounds like a strong term - however, if an implementation chooses not to implement the PEP, it can do whatever it wants, including omission of required fields.
Please let me rephrase my suggestion. If an implementation wants implemented the PEP it is required to provide a well defined set of attributes. Of course I'm open for any suggestions regarding names, specification and content of the attribues.
Doing some bike-shedding: I'd like to not use "cpython" as the name of the python.org implementation. This term, I believe, was coined around JPython, somehow making the implementation language the primary means of distinction. However, there may be alternative implementations written in C (e.g. unladen swallow), or otherwise be "C based" (e.g. pypy).
So I propose that the python.org version is identified as "python".
CPython is a well established term that is widely used to distinguish between multiple implementations of Python as a language. On the one hand the python.org implementation was the first one. It founded the language and made it popular. On the other hand it may look arrogant from the perspective of the other implementors if we choose to use "python" as the identifier for the python.org implementation. In my opinion we should let Guido decide about the identifier before we have another bike-shedding war. ;-)
name (required): mixed case name of the implementation, for example "CPython", "IronPython", "Jython", "PyPy"
Likewise; alternatively "python.org".
Interesting suggestion. Guido? Christian
Martin v. Löwis wrote:
Doing some bike-shedding: I'd like to not use "cpython" as the name of the python.org implementation. This term, I believe, was coined around JPython, somehow making the implementation language the primary means of distinction. However, there may be alternative implementations written in C (e.g. unladen swallow), or otherwise be "C based" (e.g. pypy).
However, CPython has been used for years to distinguish CPython-the-reference-implementation from Python-the-language-definition. Starting to call it something else now would just confuse people for no good reason. As Greg said, it may be better to think of it as standing for "Classic Python" rather than merely "A Python interpreter written in C". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Fri, Oct 9, 2009 at 8:42 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I think it is important to confirm in advance that all the implementations listed below agree to implement the PEP "soonish" after it's adopted. "Required" sounds like a strong term - however, if an implementation chooses not to implement the PEP, it can do whatever it wants, including omission of required fields. Speaking for Jython, so far it looks like something we would adopt soonish after it was accepted (it looks pretty useful to me).
So I propose that the python.org version is identified as "python". I'll add my voice to the group that likes "cpython" and "CPython" as the identifier of the python.org implementation. This version has a long history, and "Classic Python" has a nice sound to it. :) -- also I hope (but won't hold my breath) that Python becomes more associated with the abstract language in time.
-Frank
On Sun, Oct 11, 2009 at 4:31 PM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
On Fri, Oct 9, 2009 at 8:42 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
So I propose that the python.org version is identified as "python".
I'll add my voice to the group that likes "cpython" and "CPython" as the identifier of the python.org implementation. This version has a long history, and "Classic Python" has a nice sound to it. :)
Regardless of the history, "CPython" is indeed how most people refer to this implementation *whenever the distinction matters*, so in a variable used to identify the implementation this makes sense to me, even though most people most of the time don't make this distinction. I'm not worried about other implementations written in C aspiring to the name CPython.
-- also I hope (but won't hold my breath) that Python becomes more associated with the abstract language in time.
Me too (on both accounts :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
"Martin v. Löwis" wrote:
id (required): lower case identifier, for example "cpython", "ironpython", "jython", "pypy"
Doing some bike-shedding: I'd like to not use "cpython" as the name of the python.org implementation. This term, I believe, was coined around JPython, somehow making the implementation language the primary means of distinction. However, there may be alternative implementations written in C (e.g. unladen swallow), or otherwise be "C based" (e.g. pypy).
So I propose that the python.org version is identified as "python".
The CPython name is the traditional and commonly used name of the python.org C implementation. Even though the name is inspired by using C as implementation language, it doesn't refer to CPython being the only implementation of Python in C. I don't think there's a need to do any bike shedding on well established names. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 12 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes <lists@cheimes.de> wrote:
I'm proposing two new attributes in the sys module: sys.implementation and sys.userdirsuffix.
This seems like a good idea. I'm not sure this idea will easily be accepted, but I'd like to see the sys module eventually split up in two parts, so it is very obvious to both implementers and users which system-specific features are portable and which are not: a) implementation details of the C implementation (subversion, _*, dllhandle, dont_write_bytecode, settscdump, ..) in one module, b) portable functionality (interpreter name and version etc, builtin_module_names, copyright, excepthook, settrace, ..) in the other - Willem (CLPython)
Willem Broekema <metawilm <at> gmail.com> writes:
a) implementation details of the C implementation (subversion, _*, dllhandle, dont_write_bytecode, settscdump, ..) in one module,
b) portable functionality (interpreter name and version etc, builtin_module_names, copyright, excepthook, settrace, ..) in the other
Where does _getframe() end? :) Regards Antoine.
2009/10/10 Willem Broekema <metawilm@gmail.com>:
On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes <lists@cheimes.de> wrote:
I'm proposing two new attributes in the sys module: sys.implementation and sys.userdirsuffix.
This seems like a good idea.
I'm not sure this idea will easily be accepted, but I'd like to see the sys module eventually split up in two parts, so it is very obvious to both implementers and users which system-specific features are portable and which are not:
I'm afraid this has already been proposed and rejected. See http://www.python.org/dev/peps/pep-3139/. -- Regards, Benjamin
Christian Heimes wrote:
Fellow Python developers!
In the light of our recent discussion about implementation specific information and user site directory I like to start a new PEP. Much to my regret I wasn't able to contribute to Python core development over the past months. I hope I can find some free time over the next weeks.
Before I start with the PEP I like to reach consensus over the goal. Alternative implementations of our beloved programming languages are becoming more important every day. Although IronPython, Jython and PyPy are trying hard to get as compatible to CPython as possible there are numerous reasons for conditional code. General Python unit tests vs. CPython specific unit tests are one reasons, implementation specific module search paths are another. At the moment Python has no easy way to inspect the implementation besides some code in the platform module.
I'm proposing two new attributes in the sys module: sys.implementation and sys.userdirsuffix.
Why not just sys.implementation as a string? Everything else can trivially be deduced from that anyway. What is the use-case for the extra information? Michael
sys.implementation ------------------
(Proposed by Nick, MAL and others.)
sys.implementation is a PyStructSequence that contains various information about the current implementation. Some fields are required to be present on every implementation. Implementations may choose to add additional fields as they see fit. Some fields like compiler are useful for introspection and are already part of sys.version. I like to include them for the sake of completeness.
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"
platform (required): platform or language of the implementation, for example "C", ".NET", "Java"
runtime (required): lower case runtime library of the implementation, for example "libc", "msvcrt90", "java6", ".net"
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"
...
sys.userdirsuffix -----------------
sys.userdirsuffix is an implementation and platform specific string that is used to construct the path for the user site directory as explained in PEP 370. The string contains the implementation name as well as the version number of Python.
Examples: python2.6 (CPython, Unix) Python26 (CPython, Windows) ironpython2.6 (IronPython, Unix) IronPython26 (IronPython, Windows) ...
Comments?
Christian
_______________________________________________ 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/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
Michael Foord wrote:
Why not just sys.implementation as a string? Everything else can trivially be deduced from that anyway. What is the use-case for the extra information?
I think Christian's set of required attributes is much too large (I would only have "name" as a required field), but I can understand the desire to use a structure rather than a simple string. As with sys.float_info, it gives a new namespace to store "info about the implementation" without throwing more and more stuff into the main sys namespace. So it might start with just "name" being compulsory (since people can use lower() to iron out any capitalisation issues), but allow implementation specific attributes to migrate from the sys module to the implementation namespace. So "url" might become a common attribute, with each implementation providing a pointer to their homepage. CPython might decide to put our eventual Hg based replacement for sys.subversion under sys.implementation instead of at the module level, etc. A designated location for "put your implementation specific attributes here" inside the sys module is a lot less hassle than creating a whole new module for the purpose, but gives most of the same benefits. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Christian Heimes wrote:
sys.implementation ------------------
platform (required): platform or language of the implementation, for example "C", ".NET", "Java"
I'd call this attribute "language". We already have sys.platform with a different meaning. Possible values would then be "C", "C#", "Java", "Python", etc.
runtime (required): lower case runtime library of the implementation, for example "libc", "msvcrt90", "java6", ".net"
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"
If you include the compiler as well, it may make sense to also add the other creation details that platform.py parses from the sys.version string: branch, revision, buildno, builddate
...
sys.userdirsuffix -----------------
sys.userdirsuffix is an implementation and platform specific string that is used to construct the path for the user site directory as explained in PEP 370. The string contains the implementation name as well as the version number of Python.
Don't we already have this information available as site.getuserbase()/ site.getusersitepackages() ?
Examples: python2.6 (CPython, Unix) Python26 (CPython, Windows) ironpython2.6 (IronPython, Unix) IronPython26 (IronPython, Windows) ...
Since the examples point to the name of the Python stdlib dir and this form is also used in a lot of other places to distinguish different Python versions (e.g. in distutils build dirs), perhaps we should use a more generic name for it like e.g. sys.versiondir ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 12 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
M.-A. Lemburg wrote:
sys.userdirsuffix -----------------
sys.userdirsuffix is an implementation and platform specific string that is used to construct the path for the user site directory as explained in PEP 370. The string contains the implementation name as well as the version number of Python.
Don't we already have this information available as site.getuserbase()/ site.getusersitepackages() ?
No, the new attribute is intended to allow a VM implementation to customise the way site.py calculates the user directories so that CPython, Jython, IronPython, etc, don't have to share the same directory. CPython will stick with the directory as named in PEP 370 (since we already released a version with that behaviour), but the other implementations will be able to choose a name that doesn't conflict with it. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
M.-A. Lemburg wrote:
sys.userdirsuffix -----------------
sys.userdirsuffix is an implementation and platform specific string that is used to construct the path for the user site directory as explained in PEP 370. The string contains the implementation name as well as the version number of Python.
Don't we already have this information available as site.getuserbase()/ site.getusersitepackages() ?
No, the new attribute is intended to allow a VM implementation to customise the way site.py calculates the user directories so that CPython, Jython, IronPython, etc, don't have to share the same directory.
CPython will stick with the directory as named in PEP 370 (since we already released a version with that behaviour), but the other implementations will be able to choose a name that doesn't conflict with it.
Ah, so it's intended to provide information to site.getuserbase()/ site.getusersitepackages() ? Still, since that path name component is used in other contexts as well, wouldn't it be better to have all those contexts use the name ?! Python has always used the (lib|include)/pythonX.Y/ path naming scheme on Unix, but it's not codified anywhere. A sys attribute or a set of such attributes would be good way to do so. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
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@scottdial.com scodial@cs.indiana.edu
participants (14)
-
"Martin v. Löwis" -
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon -
Christian Heimes -
Dino Viehland -
Frank Wierzbicki -
Greg Ewing -
Guido van Rossum -
M.-A. Lemburg -
Michael Foord -
Nick Coghlan -
Scott Dial -
Willem Broekema