sys.implementation

The proposal of adding sys.implementation has come up a couple times over the last few years. [1][2] While the reaction has been overwhelmingly positive, nothing has come of it. I've created a tracker issue and a patch: http://bugs.python.org/issue14673 The patch adds a struct sequence that holds ("name" => "CPython", "version" => sys.version_info). If later needs dictate more fields, we can cross that bridge then. Are there any objections? Considering the positive reaction and the scope of the addition, does this need a PEP? -eric [1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html [2] http://mail.python.org/pipermail/python-ideas/2012-April/014878.html

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw <barry@python.org> wrote:
It's somewhat of a corner case, but I think a PEP couldn't hurt. The rationale section would be useful, at least.
http://mail.python.org/pipermail/python-ideas/2012-April/014954.html -eric

On 4/27/2012 12:34 AM, Eric Snow wrote:
The idea of having separate versions for CPython and stdlib has been raised recently, although I believe it has been mostly been deferred or discarded. Should that be resurrected, sys.implementation may be a good repository for the additional version info defining the stdlib version. However, this PEP raises the following question in my mind: is the sys module part of the stdlib? Before reaching a hasty conclusion, consider the following points: 1) with this proposal, the contents of sys.implementation will vary between implementations. If stdlib is to be shared among implementations, then it seems sys.implementation should not be part of the stdlib, but rather part of the implementation. Is sys considered part of the implementation or part of the stdlib? I've always perceived it as part of the stdlib, because of the way it is documented. 2) importlib wants to be part of the stdlib, and thus available to other implementations, but it must be built-in or frozen. The goal with importlib is a common implementation in Python, that can be used by all implementations. I am not clear on whether the accelerated C code is part of the stdlib, or part of an implementation optimization, nor how the structuring of such things is arranged to separate stdlib from implementation (if it is; if it isn't, should it be?) 3) can anything that must be built-in or frozen be part of the stdlib? I don't see why not, if it is common to all implementations, even if it depends on data it obtains from the implementation via some mechanism such as the proposed sys.implementation. However, if it is not common, I don't know how it can be standard/stdlib... which raises issues in my understanding of the various modules available as Python with C accelerators, and I know there are pure C modules that are part of the stdlib. So I think this idea of making the stdlib more sharable between implementations is still a work-in-progress, even a design-in-progress, but maybe part of the solution is to separate, or at least delineate, things that can be common, from things that cannot be common to all implementations. My conclusion is that sys.implementation clearly should not be part of the stdlib, but rather be part of the language implementation. Whether it then fits with the rest of what is in sys, or not, I am not qualified to say. If not, perhaps a new module name is warranted... perhaps "implementation" at the top level of the namespace. So my thoughts are: Things that are part of the stdlib should be available in Python source to be shared across implementations. Things that are not available in Python source cannot be shared across implementations, and therefore should not be part of the stdlib, but rather part of an implementation-specific library, or part of the language specification. Or maybe stdlib should be an umbrella term, with the following subsets: common (Python implementation available, and not dependent on implementation-specific details except in very standardized ways), implementation-specific (provided by each implementation, either in implementation-specific Python, or some other implementation language), accelerators (a faster version of a common module, provided by an implementation when necessary for performance). In this situation, sys.implementation, as proposed, should be implementation-specific.

On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman <v+python@g.nevcal.com> wrote:
IMO, there are two different things here that you are conflating(*): the *implementation* of the stdlib, and the stdlib *API*. sys.implementation would be a part of the API that any conforming implementation of python+stdlib would be required to implement. We also have a goal of making as much of the *implementation* of the stdlib usable by any python implementation as possible, but as you say that is a work in progress. There are, by the way, many things documented in the "library" documentation that are in fact provided by the language implementation itself. All of the fundamental types, for example. --David (*) the Oracle lawyers sometimes seem to be trying to get the judge and jury to make the same mistake.

On 4/27/2012 11:49 AM, R. David Murray wrote:
Hmm. OK.
OK.
I was aware of this last, but wasn't thinking about it during these musings... although the thoughts of documentation also crossed my mind, I didn't mention them, figuring it could come up later. So "library" documentation already covers all three categories of stuff that I mentioned, plus one more (restated here for clarity, with better wording): * language implementation * implementation dependent modules * implementation independent modules * implementation dependent optimizations of implementation independent modules From the perspective of a user of a single implementation of the language + library, it really doesn't matter how the documentation is organized, or whether the documentation notes which of the above 4 categories an item falls in. From the perspective of a user of multiple implementations, or perspective of a developer of an implementation other than CPython, knowledge of the category could be useful for both portability and performance planning. Organizing the documentation in some manner to be aware of such categories may help other implementations provide appropriate addenda. The closer any of them get to tracking the Py3 trunk in real time, the more so. Here's a ponderable: In the long term, should the documentation be unified for multiple implementations? Or should it be split into 4 pieces, so that alternate implementations could swap in their own sections for implementation dependent items?

On Sat, Apr 28, 2012 at 6:11 AM, Glenn Linderman <v+python@g.nevcal.com> wrote:
Probably not, because the boundary between language, standard library and implementation *is* blurry. The blurriness in the descriptions reflects the blurriness in reality. Anything that doesn't have dedicated syntax is, in a formal sense, part of the standard library rather than the core language definition. That includes the GC API, the weakref API, the sys module, the operator module, the builtins module, the types module, etc. The language specification itself just states that there *is* a builtin namespace and you *can* do imports. It is then up to the standard library specification to describe the *contents* of the builtin namespace, as well as state what other modules and packages can be imported by default. However, the various parts of the standard library differ can wildly in how *closely coupled* they are to a particular implementation. Some, such as builtins, gc, operator, weakref, types and sys are *very* tightly coupled with a specific implementation and always will be. If someone is writing a new implementation of Python, they're almost certainly going to have to write new version of these modules from scratch that interoperate correctly with their code generator and evaluation loop. Historically, the import machinery was similarly coupled to a specific implementation. The goal of bootstrapping importlib as the main import implementation is to change that so that most of the import machinery is decoupled from the implementation, with the bare minimum remaining as implementation specific code (specifically, the code needed to carry out the bootstrapping process, such as supporting frozen and builtin modules). Other modules may differ in performance characteristics between implementations, particular for older C modules in CPython which don't have a pure Python counterpart. So, yes, I agree the four categories you list are helpful in *thinking* about the questions involved, but, no, I don't think it's a good principle for organising the documentation (precisely because the categories are related to implementation details that shouldn't matter all that much to end users). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 27.04.2012 09:34, Eric Snow wrote:
Interesting proposal. I have a number of comments: - namespace vs. dictionary. Barry was using it in the form sys.implementation.version. I think this is how it should work, yet the PEP says that sys.implementation is a dictionary, which means that you would need to write sys.implementation['version'] I think the PEP should be silent on the type of sys.implementation, in particular, it should not mandate that it be a module (else "from sys.implementation import url" ought to work) [Update: it seems this is already reflected in the PEP. I wonder where the requirement for "a new type" comes from. I think making it a module should be conforming, even though probably discouraged for cpython, as it would make people think that they can rely on it being a module. I wish there was a builtin class class record: pass which can be used to create objects which have only attributes and no methods. Making it a type should also work: class implementation: name = "cpython" version = (3,3,0) in which case it would an instance of an existing type, namely, "type"] - under-specified attributes: "run-time environment" doesn't mean much to me - my first guess is that it is the set of environment variables, i.e. a dictionary identical to os.environ. I assume you mean something different ... gc_type is supposedly a string, but I cannot guess what possible values it may have. I also wonder why it's relevant. Regards, Martin

On Wed, May 9, 2012 at 5:57 AM, "Martin v. Löwis" <martin@v.loewis.de>wrote:
That stems from people arguing over whether sys.implementation should be a dict or a tuple, and people going "it shouldn't be a sequence since it lacks a proper order", but then others saying "it shouldn't be a dict because it isn't meant to be mutated" (or something since I argued for the dict). So Eric (I suspect) went with what made sense to him.
I have heard this request now a bazillion times over the years. Why don't we have such an empty class sitting somewhere in the stdlib with a constructor classmethod to simply return new instances (and if you want to get really fancy, optional keyword arguments to update the instance with the keys/values passed in)? Is it simply because it's just two lines of Python that *everyone* has replicated at some point? -Brett

On Wed, 9 May 2012 10:44:59 -0400 Brett Cannon <brett@python.org> wrote:
In this case, it's because sys is a built-in module written in C, and importing Python code is a no-go. We have a similar problem with ABCs: io jumps through hoops to register its implementation classes with the I/O ABCs. Regards Antoine.

On Wed, May 9, 2012 at 8:50 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Something I've remotely considered is an approach like namedtuple takes: define a pure Python template, .format() it, and exec it. However, this is partly a reflection of my lack of familiarity with using the C-API. As well, the only place I've seen this done in the CPython code base is with namedtuple. Consequently, I was planning on taking the normal approach. Should the namedtuple-exec technique be avoided at the C level? -eric

On Thu, May 10, 2012 at 2:53 AM, Barry Warsaw <barry@python.org> wrote:
Please, no. No new just-like-a-namedtuple-except-you-can't-iterate-over-it type, and definitely not one exposed in the collections module. We've been over this before: collections.namedtuple *is* the standard library's answer for structured records. TOOWTDI, and the way we have already chosen includes iterability as one of its expected properties. People shouldn't be so quick to throw away ordered iterability - it makes a lot of things like generic display routines and serialisation *much* easier, and without incurring the runtime cost of multiple calls to sorted(). The original concern (that sys.implementation may differ in length across implementations) has been eliminated by moving all implementation specific values into sys.implementation.metadata. The top-level record now has a consistent length for any given language version. The fact that the length of the record may still change in *future* versions of Python can be handled through documentation - we can simply tell people "it's OK to iterate over the fields, and even to use tuple unpacking, but if you want to future proof your code, make sure to include the trailing ', *' to ignore any fields that get added in the future". To help focus the discussion, I am going to propose a specific (albeit still somewhat hypothetical) use case: a cross-implementation testing system that wants to be able to consistently capture data about the version of Python that was tested, *without* needing implementation specific code in the metadata capture step. That produces the following set of requirements: 1. sys.implementation should be immutable for a given execution of Python 2. repr(sys.implementation) should display all recorded details of the implementation 3. It should be possible to write a generic, future-proof, serialisation of sys.implementation that captures all recorded details collections.namedtuple meets all those requirements (_structseq doesn't meet the last one at this point, but more on that later) It also shows that we only need to place very minimal constraints on sys.implementation.metadata: the type of that structure can be entirely up to the implementation, with the only requirement being that repr(sys.implementation.metadata) should produce a string that accurately captures the stored information. The only cross-implementation operation that is supported on that field would be to take its representation. Now, because this is going to be in the sys module, for CPython, we would actually need to use _structseq rather than collections.namedtuple. To do so in a useful way, _structseq should get two new additions: - the "_fields" attribute - the "_asdict" method As an added bonus, sys.float_info and sys.hash_info would also gain the new operations. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, May 9, 2012 at 7:33 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Good point. I'd forgotten about that new tuple unpacking syntax. FYI, a named tuple was my original choice. I'm going to sit on this a few days though. Who knows, we might be back to using a dict by then. <wink> Key points: * has dotted access * is immutable Both reflect the nature of sys.implementation as currently described (a fixed set of attributes on an dotted-access namespace).
Nice.
Sounds good to me regardless of the PEP. -eric

On Thu, May 10, 2012 at 3:34 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Yes, please. One of the original arguments that delayed the introduction of the collections module was the fear that it would lead to the introduction of tons of subtly different data types, making it substantially harder to choose the right data type for a given application. I see this proposal as the realisation of that fear. Unordered types can be a PITA for testing, for display and for generic serialisation, so I definitely want to see a PEP before we add a new one that basically has its sole reason for existence being "you can iterate over and index the field values in a namedtuple". Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 5/10/2012 1:40 AM, Nick Coghlan wrote:
I could use those same arguments (testing, display, and generic serialization) as reasons /against/ using an ordered type (when it's not the intent of the author that it be ordered). That is: - Testing: This is an attractive nuisance because adding fields later can break the tests if the author of the type had no intent on the ordering being guaranteed (or the number of fields). - Display: If the author of the type didn't intend on the ordering being guaranteed, then the display could become nonsense when changing versions (e.g., upgrading a 3rd-party library). - Generic Serialization: Again, if the author didn't plan for that, then they could add additional fields or re-arrange them in a way that makes naive serialization give incorrect instances. The point is that the author of the type can't protect you from these mistakes if a namedtuple is used. The only tool the author of the type has at their disposal to warn you of your ways is documentation. If the type doesn't support iteration or indexing, then you are forced to do it right, because it's the only way that works. Furthermore, what is wrong with a repr that yields a dict-like string "record(a=1, b=2, c=3)" with regard to testing and display? -- Scott Dial scott@scottdial.com

Scott Dial wrote:
As opposed to unordered types when you add a new field? I don't think so. When you add new fields, you can break tests *regardless* of whether the type is ordered or unordered. If you change the public interface to a type, you have to change any tests that rely on it. But unordered types have a tendency to break tests even when you don't add new fields (at least doctests), simply because their display can arbitrarily change. Given the choice between having to re-write tests once in a blue moon when there is a backwards-incompatible change to a type, and having tests randomly break every time I run them because the display is unpredictable, I know which one I prefer. +1 to Nick's request for a PEP. -- Steven

On Thu, 10 May 2012 11:33:14 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
Uh. It's scary the kind of things people sometimes come up with :-) sys.implementation.metadata looks like a completely over-engineered concept. Please, let's just make sys.implementation a dict and stop bothering about ordering and iterability. Regards Antoine.

On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Aye. Add a rule that all implementation specific (i.e. not defined in the PEP) keys must be prefixed with an underscore and I'm sold. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Nick Coghlan wrote:
So now we're adding a new convention to single underscore names? Single underscore names are implementation-specific details that you shouldn't use or rely on, except in sys.implementation, where they are an optional part of the public interface. There are public keys which all Pythons are expected to support. There are public keys which only some Pythons are expected to support. We may call them "implementation-specific", but that refers to the PYTHON implementation, not the implementation of sys.implementation. As far as sys.implementation is concerned, these keys are public but optional, not private. Hence labelling them with a single underscore overrides the convention that _single underscore names are private, for one that they are public but optional. I'm not so sure that this is a good idea. To bike-shed a moment, if we're going to stick to a dict, and you really think that it is important to have a naming convention to distinguish between optional keys and those common to all Pythons, perhaps a better convention would be to prefix the optional keys with a dot, or a dash. This introduces a new convention without clashing with an existing one. -- Steven

No, they're private keys for the benefit of the implementation authors. Still, it's already the case that underscore prefixed names are sometimes used just for namespace separation (e.g. collections.namedtuple) -- Sent from my phone, thus the relative brevity :)

On Thu, May 10, 2012 at 3:39 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I've always seen _names as less implementation details and more 'here be dragons; tread carefully'. I don't think adding a different convention really changes that at all. The underscore ones would (mostly) be implementation-specific anyway. _clr_version is something only IronPython is going to have, for example. If more than one implementation has something it can be promoted to a non-underscore name, but I think that will be rare. Some of the suggested metadata (like vcs_revision and build date) could actually be required right out of the gate, and cache_tag should be optional. - Jeff

The specific reason cache_tag is mandatory is so that importlib can rely on it. Setting it to None for a given implementation will automatically disable caching of bytecode files. -- Sent from my phone, thus the relative brevity :)

On 5/10/2012 10:42 AM, Georg Brandl wrote:
Thank you for cutting through the knot.
Agreed.
Ditto. Iterability is good and should be part of all python collections. People who want a sorted representation should just use sorted(d.items) as with other sortable mappings. Nick's idea of prefixing local implementation keys with '_' would nicely group them together on sorted displays. -- Terry Jan Reedy

On May 10, 2012, at 10:57 AM, Antoine Pitrou wrote:
I guess the question is whether immutability is useful to preserve in sys.implementation. I'm on the fence, but maybe "we're all consenting adults" and "simplest thing that will work" should rule the day. Using a straight up dict and underscores for non-PEP-defined values is certainly simple, and easy to implement and describe. -Barry

On Thu, May 10, 2012 at 2:57 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I'm fine with ditching "metadata". The PEP will say sys.implementation must have the required attributes and leave it at that. However, my preference is still for dotted access rather than a dict. The type doesn't really matter to me otherwise. Immutability isn't a big concern nor is sequence-ness. I'll tone the type discussion accordingly. If anyone has strong feelings for item-access over attribute-access, please elaborate. I'm just not seeing it as that important and would rather finish up the PEP as simply as possible. -eric

On Sat, May 12, 2012 at 12:40 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
I object to adding a new type to the stdlib just for this PEP. Since iterating over the keys is significantly more useful than iterating over the values, that suggests a dictionary as the most appropriate type. If someone *really* wants a quick way to get dotted access to the contents of dictionary:
Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On May 12, 2012, at 10:04 PM, Nick Coghlan wrote:
I'm okay with dropping immutability for sys.implementation, but I still think attribute access is a more useful model. You can easily support both getattr and getitem with a class instance, so I think that's the way to go. (FWIW, immutability would also be easy to support with an instance.) -Barry

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/12/2012 08:04 AM, Nick Coghlan wrote:
Why would anyone want to iterate over either of them? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ulP8ACgkQ+gerLs4ltQ4OzACgwnmVgJzE+IdEdS0Ij1J357di bnoAni5nUCIDcZt7dwEOfLLPUZoJQYF9 =t05/ -----END PGP SIGNATURE-----

On Sat, May 12, 2012 at 10:51 AM, Tres Seaver <tseaver@palladion.com> wrote:
Nick gave a pretty good example [1]. I just don't think it's necessary for the PEP. -eric [1] http://mail.python.org/pipermail/python-dev/2012-May/119412.html

Tres Seaver wrote:
1) I don't know what keys exist, so I use introspection on sys.implementation by iterating over the keys and/or values. E.g. dir(sys.implementation), or list(sys.implementation.keys()). 2) I know what keys exist, but I want to pretty-print the list of key/value pairs without having to explicitly write them out by hand: print("spam", sys.implementation.spam) print("ham", sys.implementation.ham) print("cheese", sys.implementation.cheese) # and so on... -- Steven

On Sat, May 12, 2012 at 6:04 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
And I agree with you. :) The only constraint is that it be an object with attribute access. That could be a named tuple, a module, an uninstantiated class, or whatever. A new type is not needed. If it's iterable or not is irrelevant with regards to the PEP. For the implementation I'd like it to have a good repr too, but even that's not part of the proposal. I've got the latest version of the PEP up now. It pares down the type discussion and eliminates "metadata". I figure it's good enough for what we need, and I've put adequate(?) warning that people shouldn't mess with it (consenting adults, etc.). Let me know what you think.
That's pretty cool. As a counter example, given a normal (dict-based) object you can use vars() to turn it into a dict:
I'll grant that it doesn't work for some objects (like named tuples), but for sys.implementation I don't think it matters either way. -eric

At this point I'm pretty comfortable with where PEP 421 is at. Before asking for pronouncement, I'd like to know if anyone has any outstanding concerns that should be addressed first. The only (relatively) substantial point of debate has been the type for sys.implementation. The PEP now limits the specification of the type to the minimum (Big-Endian vs. Little...er...attribute-access vs mapping). If anyone objects to the decision there to go with attribute-access, please make your case.
Thanks! -eric

On Wed, May 9, 2012 at 3:57 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Interesting proposal. I have a number of comments:
Thanks for taking a look, Martin.
The type for sys.implementation has slowly shifted from the original proposal. At this point it's settled into where I think it will stay, a custom type. I've covered the choice of type in the rationale section. However, there may be merit in not being so specific about the type. I'll give that some thought.
Sorry for the confusion. These are from the examples section for sys.implementation.metadata. I believe the current version of the PEP is more clear on the distinction. Thanks again for the feedback. -eric

Hi Eric, Great job on the latest PEP 421. I really like it. A few additional comments/questions. * sys.implementation.version This is defined as the version of the implementation, while sys.version_info is the version of the language. The semantics of sys.version_info have been sufficiently squishy in the past, as the XXX implies. This PEP shouldn't try to untangle that, so I think it be better to represent both values explicitly in sys.implementation. * Adding new required variables. I'd claim that it's not unduly heavyweight to require a new PEP to add required variables to sys.implementation. That hypothetical PEP will have to include things like rationale, impact on other implementations, etc. That seems like enough to warrant a new PEP, even if it's relatively succinct. I'd also make it clear that adding new variables to sys.implementation.metadata explicitly does *not* require a PEP. * In Example Metadata Value: "If they later have meaningful uses cases, they can be added by following the process described in Adding New Required Attributes." I'd rephrase this to "If these or any other variables are deemed to have meaningful use cases across all implementations, they can be moved or added to sys.implementation directly, following the process described in Adding New Required Attributes." * I mildly prefer sys.implementation.name to be lower cased. My intuition is that to be safe, most comparisons of the value will coerce to lower case, which is easy enough in Python, but perhaps a bit more of a pain in C. I don't feel really strongly about this though. (A counter argument is that the value might be printed, so a case-sensitive version would be better.) * Since I'm advocating to be explicit about the language version and the implementation version, .hexversion is probably also useful for both. * I've said before that I think the keys in sys.implementation should be locked down (i.e. not writable). I think sys.implementation.metadata should be the same type. Cheers, -Barry

On Tue, May 8, 2012 at 7:14 PM, Barry Warsaw <barry@python.org> wrote:
Hi Eric,
Great job on the latest PEP 421. I really like it.
Encouragement appreciated. :)
Definitely tangled. So, sys.implementation.version and sys.implementation.lang_version? Also, my inclination is to not have a sys.version equivalent in sys.implementation for now, in the interest of keeping things as bare-bones as possible to start.
Agreed. I'll go with that for the PEP.
I'd also make it clear that adding new variables to sys.implementation.metadata explicitly does *not* require a PEP.
Good point.
That's an important distinction. I'll clean it up.
I'm not sure it makes a lot of difference. Since cache_tag will be provided by the implementation, I don't have any strong use-cases that would constrain the name itself. Still, my preference is for lower case as well. I'll mull this one over.
* Since I'm advocating to be explicit about the language version and the implementation version, .hexversion is probably also useful for both.
That's fine with me, and pretty trivial to do.
* I've said before that I think the keys in sys.implementation should be locked down (i.e. not writable).
I've been on and off about this. It's certainly not too hard to do, it makes sense, and I don't see a lot of reason not to do it. I'll give it a go.
I think sys.implementation.metadata should be the same type.
This I wonder about. The more I think about it, the more it fits. I'll give it a day and if that still holds I'll work it in. Thanks for the feedback, Barry! Feels like the PEP's getting close. -eric

On May 08, 2012, at 09:03 PM, Eric Snow wrote:
I think it would be fine, if PEP 421 was clear about the semantics of sys.implementation.version and was silent about trying to disentangle the semantics of sys.version. IOW, the PEP can say that the semantics of sys.version are fuzzy, but not try to clear it up. Then it would be explicit (as it already is) that sys.implementation.version describes the version of the implementation, not the version of the language compliance. If the latter is useful later, then it can use the PEP 421 described process to propose a new sys.implementation value that describes a language compliance variable.
Cool. As I said, I'm on the fence about it too. :)
Maybe it doesn't matter. We're all adults here. I think there are two good choices. Either the PEP explicitly describes sys.implementation as immutable, or it is silent about it. IOW, I don't think the PEP should explicitly allow sys.implementation to be mutable.
Cool.
Thanks for the feedback, Barry! Feels like the PEP's getting close.
Indeed! Cheers, -Barry

On Wed, May 9, 2012 at 10:39 AM, Barry Warsaw <barry@python.org> wrote:
Whoops. I meant that I'm okay with having sys.implementation.version and sys.implementation.lang_version, both as analogs to sys.version_info. My inclination is to not include the analog to sys.version. However, with the way that you put it, I think you're right that we could put off the lang_version attribute for later.
Agreed. -eric

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw <barry@python.org> wrote:
It's somewhat of a corner case, but I think a PEP couldn't hurt. The rationale section would be useful, at least.
http://mail.python.org/pipermail/python-ideas/2012-April/014954.html -eric

On 4/27/2012 12:34 AM, Eric Snow wrote:
The idea of having separate versions for CPython and stdlib has been raised recently, although I believe it has been mostly been deferred or discarded. Should that be resurrected, sys.implementation may be a good repository for the additional version info defining the stdlib version. However, this PEP raises the following question in my mind: is the sys module part of the stdlib? Before reaching a hasty conclusion, consider the following points: 1) with this proposal, the contents of sys.implementation will vary between implementations. If stdlib is to be shared among implementations, then it seems sys.implementation should not be part of the stdlib, but rather part of the implementation. Is sys considered part of the implementation or part of the stdlib? I've always perceived it as part of the stdlib, because of the way it is documented. 2) importlib wants to be part of the stdlib, and thus available to other implementations, but it must be built-in or frozen. The goal with importlib is a common implementation in Python, that can be used by all implementations. I am not clear on whether the accelerated C code is part of the stdlib, or part of an implementation optimization, nor how the structuring of such things is arranged to separate stdlib from implementation (if it is; if it isn't, should it be?) 3) can anything that must be built-in or frozen be part of the stdlib? I don't see why not, if it is common to all implementations, even if it depends on data it obtains from the implementation via some mechanism such as the proposed sys.implementation. However, if it is not common, I don't know how it can be standard/stdlib... which raises issues in my understanding of the various modules available as Python with C accelerators, and I know there are pure C modules that are part of the stdlib. So I think this idea of making the stdlib more sharable between implementations is still a work-in-progress, even a design-in-progress, but maybe part of the solution is to separate, or at least delineate, things that can be common, from things that cannot be common to all implementations. My conclusion is that sys.implementation clearly should not be part of the stdlib, but rather be part of the language implementation. Whether it then fits with the rest of what is in sys, or not, I am not qualified to say. If not, perhaps a new module name is warranted... perhaps "implementation" at the top level of the namespace. So my thoughts are: Things that are part of the stdlib should be available in Python source to be shared across implementations. Things that are not available in Python source cannot be shared across implementations, and therefore should not be part of the stdlib, but rather part of an implementation-specific library, or part of the language specification. Or maybe stdlib should be an umbrella term, with the following subsets: common (Python implementation available, and not dependent on implementation-specific details except in very standardized ways), implementation-specific (provided by each implementation, either in implementation-specific Python, or some other implementation language), accelerators (a faster version of a common module, provided by an implementation when necessary for performance). In this situation, sys.implementation, as proposed, should be implementation-specific.

On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman <v+python@g.nevcal.com> wrote:
IMO, there are two different things here that you are conflating(*): the *implementation* of the stdlib, and the stdlib *API*. sys.implementation would be a part of the API that any conforming implementation of python+stdlib would be required to implement. We also have a goal of making as much of the *implementation* of the stdlib usable by any python implementation as possible, but as you say that is a work in progress. There are, by the way, many things documented in the "library" documentation that are in fact provided by the language implementation itself. All of the fundamental types, for example. --David (*) the Oracle lawyers sometimes seem to be trying to get the judge and jury to make the same mistake.

On 4/27/2012 11:49 AM, R. David Murray wrote:
Hmm. OK.
OK.
I was aware of this last, but wasn't thinking about it during these musings... although the thoughts of documentation also crossed my mind, I didn't mention them, figuring it could come up later. So "library" documentation already covers all three categories of stuff that I mentioned, plus one more (restated here for clarity, with better wording): * language implementation * implementation dependent modules * implementation independent modules * implementation dependent optimizations of implementation independent modules From the perspective of a user of a single implementation of the language + library, it really doesn't matter how the documentation is organized, or whether the documentation notes which of the above 4 categories an item falls in. From the perspective of a user of multiple implementations, or perspective of a developer of an implementation other than CPython, knowledge of the category could be useful for both portability and performance planning. Organizing the documentation in some manner to be aware of such categories may help other implementations provide appropriate addenda. The closer any of them get to tracking the Py3 trunk in real time, the more so. Here's a ponderable: In the long term, should the documentation be unified for multiple implementations? Or should it be split into 4 pieces, so that alternate implementations could swap in their own sections for implementation dependent items?

On Sat, Apr 28, 2012 at 6:11 AM, Glenn Linderman <v+python@g.nevcal.com> wrote:
Probably not, because the boundary between language, standard library and implementation *is* blurry. The blurriness in the descriptions reflects the blurriness in reality. Anything that doesn't have dedicated syntax is, in a formal sense, part of the standard library rather than the core language definition. That includes the GC API, the weakref API, the sys module, the operator module, the builtins module, the types module, etc. The language specification itself just states that there *is* a builtin namespace and you *can* do imports. It is then up to the standard library specification to describe the *contents* of the builtin namespace, as well as state what other modules and packages can be imported by default. However, the various parts of the standard library differ can wildly in how *closely coupled* they are to a particular implementation. Some, such as builtins, gc, operator, weakref, types and sys are *very* tightly coupled with a specific implementation and always will be. If someone is writing a new implementation of Python, they're almost certainly going to have to write new version of these modules from scratch that interoperate correctly with their code generator and evaluation loop. Historically, the import machinery was similarly coupled to a specific implementation. The goal of bootstrapping importlib as the main import implementation is to change that so that most of the import machinery is decoupled from the implementation, with the bare minimum remaining as implementation specific code (specifically, the code needed to carry out the bootstrapping process, such as supporting frozen and builtin modules). Other modules may differ in performance characteristics between implementations, particular for older C modules in CPython which don't have a pure Python counterpart. So, yes, I agree the four categories you list are helpful in *thinking* about the questions involved, but, no, I don't think it's a good principle for organising the documentation (precisely because the categories are related to implementation details that shouldn't matter all that much to end users). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 27.04.2012 09:34, Eric Snow wrote:
Interesting proposal. I have a number of comments: - namespace vs. dictionary. Barry was using it in the form sys.implementation.version. I think this is how it should work, yet the PEP says that sys.implementation is a dictionary, which means that you would need to write sys.implementation['version'] I think the PEP should be silent on the type of sys.implementation, in particular, it should not mandate that it be a module (else "from sys.implementation import url" ought to work) [Update: it seems this is already reflected in the PEP. I wonder where the requirement for "a new type" comes from. I think making it a module should be conforming, even though probably discouraged for cpython, as it would make people think that they can rely on it being a module. I wish there was a builtin class class record: pass which can be used to create objects which have only attributes and no methods. Making it a type should also work: class implementation: name = "cpython" version = (3,3,0) in which case it would an instance of an existing type, namely, "type"] - under-specified attributes: "run-time environment" doesn't mean much to me - my first guess is that it is the set of environment variables, i.e. a dictionary identical to os.environ. I assume you mean something different ... gc_type is supposedly a string, but I cannot guess what possible values it may have. I also wonder why it's relevant. Regards, Martin

On Wed, May 9, 2012 at 5:57 AM, "Martin v. Löwis" <martin@v.loewis.de>wrote:
That stems from people arguing over whether sys.implementation should be a dict or a tuple, and people going "it shouldn't be a sequence since it lacks a proper order", but then others saying "it shouldn't be a dict because it isn't meant to be mutated" (or something since I argued for the dict). So Eric (I suspect) went with what made sense to him.
I have heard this request now a bazillion times over the years. Why don't we have such an empty class sitting somewhere in the stdlib with a constructor classmethod to simply return new instances (and if you want to get really fancy, optional keyword arguments to update the instance with the keys/values passed in)? Is it simply because it's just two lines of Python that *everyone* has replicated at some point? -Brett

On Wed, 9 May 2012 10:44:59 -0400 Brett Cannon <brett@python.org> wrote:
In this case, it's because sys is a built-in module written in C, and importing Python code is a no-go. We have a similar problem with ABCs: io jumps through hoops to register its implementation classes with the I/O ABCs. Regards Antoine.

On Wed, May 9, 2012 at 8:50 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Something I've remotely considered is an approach like namedtuple takes: define a pure Python template, .format() it, and exec it. However, this is partly a reflection of my lack of familiarity with using the C-API. As well, the only place I've seen this done in the CPython code base is with namedtuple. Consequently, I was planning on taking the normal approach. Should the namedtuple-exec technique be avoided at the C level? -eric

On Thu, May 10, 2012 at 2:53 AM, Barry Warsaw <barry@python.org> wrote:
Please, no. No new just-like-a-namedtuple-except-you-can't-iterate-over-it type, and definitely not one exposed in the collections module. We've been over this before: collections.namedtuple *is* the standard library's answer for structured records. TOOWTDI, and the way we have already chosen includes iterability as one of its expected properties. People shouldn't be so quick to throw away ordered iterability - it makes a lot of things like generic display routines and serialisation *much* easier, and without incurring the runtime cost of multiple calls to sorted(). The original concern (that sys.implementation may differ in length across implementations) has been eliminated by moving all implementation specific values into sys.implementation.metadata. The top-level record now has a consistent length for any given language version. The fact that the length of the record may still change in *future* versions of Python can be handled through documentation - we can simply tell people "it's OK to iterate over the fields, and even to use tuple unpacking, but if you want to future proof your code, make sure to include the trailing ', *' to ignore any fields that get added in the future". To help focus the discussion, I am going to propose a specific (albeit still somewhat hypothetical) use case: a cross-implementation testing system that wants to be able to consistently capture data about the version of Python that was tested, *without* needing implementation specific code in the metadata capture step. That produces the following set of requirements: 1. sys.implementation should be immutable for a given execution of Python 2. repr(sys.implementation) should display all recorded details of the implementation 3. It should be possible to write a generic, future-proof, serialisation of sys.implementation that captures all recorded details collections.namedtuple meets all those requirements (_structseq doesn't meet the last one at this point, but more on that later) It also shows that we only need to place very minimal constraints on sys.implementation.metadata: the type of that structure can be entirely up to the implementation, with the only requirement being that repr(sys.implementation.metadata) should produce a string that accurately captures the stored information. The only cross-implementation operation that is supported on that field would be to take its representation. Now, because this is going to be in the sys module, for CPython, we would actually need to use _structseq rather than collections.namedtuple. To do so in a useful way, _structseq should get two new additions: - the "_fields" attribute - the "_asdict" method As an added bonus, sys.float_info and sys.hash_info would also gain the new operations. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, May 9, 2012 at 7:33 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Good point. I'd forgotten about that new tuple unpacking syntax. FYI, a named tuple was my original choice. I'm going to sit on this a few days though. Who knows, we might be back to using a dict by then. <wink> Key points: * has dotted access * is immutable Both reflect the nature of sys.implementation as currently described (a fixed set of attributes on an dotted-access namespace).
Nice.
Sounds good to me regardless of the PEP. -eric

On Thu, May 10, 2012 at 3:34 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Yes, please. One of the original arguments that delayed the introduction of the collections module was the fear that it would lead to the introduction of tons of subtly different data types, making it substantially harder to choose the right data type for a given application. I see this proposal as the realisation of that fear. Unordered types can be a PITA for testing, for display and for generic serialisation, so I definitely want to see a PEP before we add a new one that basically has its sole reason for existence being "you can iterate over and index the field values in a namedtuple". Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 5/10/2012 1:40 AM, Nick Coghlan wrote:
I could use those same arguments (testing, display, and generic serialization) as reasons /against/ using an ordered type (when it's not the intent of the author that it be ordered). That is: - Testing: This is an attractive nuisance because adding fields later can break the tests if the author of the type had no intent on the ordering being guaranteed (or the number of fields). - Display: If the author of the type didn't intend on the ordering being guaranteed, then the display could become nonsense when changing versions (e.g., upgrading a 3rd-party library). - Generic Serialization: Again, if the author didn't plan for that, then they could add additional fields or re-arrange them in a way that makes naive serialization give incorrect instances. The point is that the author of the type can't protect you from these mistakes if a namedtuple is used. The only tool the author of the type has at their disposal to warn you of your ways is documentation. If the type doesn't support iteration or indexing, then you are forced to do it right, because it's the only way that works. Furthermore, what is wrong with a repr that yields a dict-like string "record(a=1, b=2, c=3)" with regard to testing and display? -- Scott Dial scott@scottdial.com

Scott Dial wrote:
As opposed to unordered types when you add a new field? I don't think so. When you add new fields, you can break tests *regardless* of whether the type is ordered or unordered. If you change the public interface to a type, you have to change any tests that rely on it. But unordered types have a tendency to break tests even when you don't add new fields (at least doctests), simply because their display can arbitrarily change. Given the choice between having to re-write tests once in a blue moon when there is a backwards-incompatible change to a type, and having tests randomly break every time I run them because the display is unpredictable, I know which one I prefer. +1 to Nick's request for a PEP. -- Steven

On Thu, 10 May 2012 11:33:14 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
Uh. It's scary the kind of things people sometimes come up with :-) sys.implementation.metadata looks like a completely over-engineered concept. Please, let's just make sys.implementation a dict and stop bothering about ordering and iterability. Regards Antoine.

On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Aye. Add a rule that all implementation specific (i.e. not defined in the PEP) keys must be prefixed with an underscore and I'm sold. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Nick Coghlan wrote:
So now we're adding a new convention to single underscore names? Single underscore names are implementation-specific details that you shouldn't use or rely on, except in sys.implementation, where they are an optional part of the public interface. There are public keys which all Pythons are expected to support. There are public keys which only some Pythons are expected to support. We may call them "implementation-specific", but that refers to the PYTHON implementation, not the implementation of sys.implementation. As far as sys.implementation is concerned, these keys are public but optional, not private. Hence labelling them with a single underscore overrides the convention that _single underscore names are private, for one that they are public but optional. I'm not so sure that this is a good idea. To bike-shed a moment, if we're going to stick to a dict, and you really think that it is important to have a naming convention to distinguish between optional keys and those common to all Pythons, perhaps a better convention would be to prefix the optional keys with a dot, or a dash. This introduces a new convention without clashing with an existing one. -- Steven

No, they're private keys for the benefit of the implementation authors. Still, it's already the case that underscore prefixed names are sometimes used just for namespace separation (e.g. collections.namedtuple) -- Sent from my phone, thus the relative brevity :)

On Thu, May 10, 2012 at 3:39 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I've always seen _names as less implementation details and more 'here be dragons; tread carefully'. I don't think adding a different convention really changes that at all. The underscore ones would (mostly) be implementation-specific anyway. _clr_version is something only IronPython is going to have, for example. If more than one implementation has something it can be promoted to a non-underscore name, but I think that will be rare. Some of the suggested metadata (like vcs_revision and build date) could actually be required right out of the gate, and cache_tag should be optional. - Jeff

The specific reason cache_tag is mandatory is so that importlib can rely on it. Setting it to None for a given implementation will automatically disable caching of bytecode files. -- Sent from my phone, thus the relative brevity :)

On 5/10/2012 10:42 AM, Georg Brandl wrote:
Thank you for cutting through the knot.
Agreed.
Ditto. Iterability is good and should be part of all python collections. People who want a sorted representation should just use sorted(d.items) as with other sortable mappings. Nick's idea of prefixing local implementation keys with '_' would nicely group them together on sorted displays. -- Terry Jan Reedy

On May 10, 2012, at 10:57 AM, Antoine Pitrou wrote:
I guess the question is whether immutability is useful to preserve in sys.implementation. I'm on the fence, but maybe "we're all consenting adults" and "simplest thing that will work" should rule the day. Using a straight up dict and underscores for non-PEP-defined values is certainly simple, and easy to implement and describe. -Barry

On Thu, May 10, 2012 at 2:57 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I'm fine with ditching "metadata". The PEP will say sys.implementation must have the required attributes and leave it at that. However, my preference is still for dotted access rather than a dict. The type doesn't really matter to me otherwise. Immutability isn't a big concern nor is sequence-ness. I'll tone the type discussion accordingly. If anyone has strong feelings for item-access over attribute-access, please elaborate. I'm just not seeing it as that important and would rather finish up the PEP as simply as possible. -eric

On Sat, May 12, 2012 at 12:40 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
I object to adding a new type to the stdlib just for this PEP. Since iterating over the keys is significantly more useful than iterating over the values, that suggests a dictionary as the most appropriate type. If someone *really* wants a quick way to get dotted access to the contents of dictionary:
Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On May 12, 2012, at 10:04 PM, Nick Coghlan wrote:
I'm okay with dropping immutability for sys.implementation, but I still think attribute access is a more useful model. You can easily support both getattr and getitem with a class instance, so I think that's the way to go. (FWIW, immutability would also be easy to support with an instance.) -Barry

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/12/2012 08:04 AM, Nick Coghlan wrote:
Why would anyone want to iterate over either of them? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ulP8ACgkQ+gerLs4ltQ4OzACgwnmVgJzE+IdEdS0Ij1J357di bnoAni5nUCIDcZt7dwEOfLLPUZoJQYF9 =t05/ -----END PGP SIGNATURE-----

On Sat, May 12, 2012 at 10:51 AM, Tres Seaver <tseaver@palladion.com> wrote:
Nick gave a pretty good example [1]. I just don't think it's necessary for the PEP. -eric [1] http://mail.python.org/pipermail/python-dev/2012-May/119412.html

Tres Seaver wrote:
1) I don't know what keys exist, so I use introspection on sys.implementation by iterating over the keys and/or values. E.g. dir(sys.implementation), or list(sys.implementation.keys()). 2) I know what keys exist, but I want to pretty-print the list of key/value pairs without having to explicitly write them out by hand: print("spam", sys.implementation.spam) print("ham", sys.implementation.ham) print("cheese", sys.implementation.cheese) # and so on... -- Steven

On Sat, May 12, 2012 at 6:04 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
And I agree with you. :) The only constraint is that it be an object with attribute access. That could be a named tuple, a module, an uninstantiated class, or whatever. A new type is not needed. If it's iterable or not is irrelevant with regards to the PEP. For the implementation I'd like it to have a good repr too, but even that's not part of the proposal. I've got the latest version of the PEP up now. It pares down the type discussion and eliminates "metadata". I figure it's good enough for what we need, and I've put adequate(?) warning that people shouldn't mess with it (consenting adults, etc.). Let me know what you think.
That's pretty cool. As a counter example, given a normal (dict-based) object you can use vars() to turn it into a dict:
I'll grant that it doesn't work for some objects (like named tuples), but for sys.implementation I don't think it matters either way. -eric

At this point I'm pretty comfortable with where PEP 421 is at. Before asking for pronouncement, I'd like to know if anyone has any outstanding concerns that should be addressed first. The only (relatively) substantial point of debate has been the type for sys.implementation. The PEP now limits the specification of the type to the minimum (Big-Endian vs. Little...er...attribute-access vs mapping). If anyone objects to the decision there to go with attribute-access, please make your case.
Thanks! -eric

On Wed, May 9, 2012 at 3:57 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Interesting proposal. I have a number of comments:
Thanks for taking a look, Martin.
The type for sys.implementation has slowly shifted from the original proposal. At this point it's settled into where I think it will stay, a custom type. I've covered the choice of type in the rationale section. However, there may be merit in not being so specific about the type. I'll give that some thought.
Sorry for the confusion. These are from the examples section for sys.implementation.metadata. I believe the current version of the PEP is more clear on the distinction. Thanks again for the feedback. -eric

Hi Eric, Great job on the latest PEP 421. I really like it. A few additional comments/questions. * sys.implementation.version This is defined as the version of the implementation, while sys.version_info is the version of the language. The semantics of sys.version_info have been sufficiently squishy in the past, as the XXX implies. This PEP shouldn't try to untangle that, so I think it be better to represent both values explicitly in sys.implementation. * Adding new required variables. I'd claim that it's not unduly heavyweight to require a new PEP to add required variables to sys.implementation. That hypothetical PEP will have to include things like rationale, impact on other implementations, etc. That seems like enough to warrant a new PEP, even if it's relatively succinct. I'd also make it clear that adding new variables to sys.implementation.metadata explicitly does *not* require a PEP. * In Example Metadata Value: "If they later have meaningful uses cases, they can be added by following the process described in Adding New Required Attributes." I'd rephrase this to "If these or any other variables are deemed to have meaningful use cases across all implementations, they can be moved or added to sys.implementation directly, following the process described in Adding New Required Attributes." * I mildly prefer sys.implementation.name to be lower cased. My intuition is that to be safe, most comparisons of the value will coerce to lower case, which is easy enough in Python, but perhaps a bit more of a pain in C. I don't feel really strongly about this though. (A counter argument is that the value might be printed, so a case-sensitive version would be better.) * Since I'm advocating to be explicit about the language version and the implementation version, .hexversion is probably also useful for both. * I've said before that I think the keys in sys.implementation should be locked down (i.e. not writable). I think sys.implementation.metadata should be the same type. Cheers, -Barry

On Tue, May 8, 2012 at 7:14 PM, Barry Warsaw <barry@python.org> wrote:
Hi Eric,
Great job on the latest PEP 421. I really like it.
Encouragement appreciated. :)
Definitely tangled. So, sys.implementation.version and sys.implementation.lang_version? Also, my inclination is to not have a sys.version equivalent in sys.implementation for now, in the interest of keeping things as bare-bones as possible to start.
Agreed. I'll go with that for the PEP.
I'd also make it clear that adding new variables to sys.implementation.metadata explicitly does *not* require a PEP.
Good point.
That's an important distinction. I'll clean it up.
I'm not sure it makes a lot of difference. Since cache_tag will be provided by the implementation, I don't have any strong use-cases that would constrain the name itself. Still, my preference is for lower case as well. I'll mull this one over.
* Since I'm advocating to be explicit about the language version and the implementation version, .hexversion is probably also useful for both.
That's fine with me, and pretty trivial to do.
* I've said before that I think the keys in sys.implementation should be locked down (i.e. not writable).
I've been on and off about this. It's certainly not too hard to do, it makes sense, and I don't see a lot of reason not to do it. I'll give it a go.
I think sys.implementation.metadata should be the same type.
This I wonder about. The more I think about it, the more it fits. I'll give it a day and if that still holds I'll work it in. Thanks for the feedback, Barry! Feels like the PEP's getting close. -eric

On May 08, 2012, at 09:03 PM, Eric Snow wrote:
I think it would be fine, if PEP 421 was clear about the semantics of sys.implementation.version and was silent about trying to disentangle the semantics of sys.version. IOW, the PEP can say that the semantics of sys.version are fuzzy, but not try to clear it up. Then it would be explicit (as it already is) that sys.implementation.version describes the version of the implementation, not the version of the language compliance. If the latter is useful later, then it can use the PEP 421 described process to propose a new sys.implementation value that describes a language compliance variable.
Cool. As I said, I'm on the fence about it too. :)
Maybe it doesn't matter. We're all adults here. I think there are two good choices. Either the PEP explicitly describes sys.implementation as immutable, or it is silent about it. IOW, I don't think the PEP should explicitly allow sys.implementation to be mutable.
Cool.
Thanks for the feedback, Barry! Feels like the PEP's getting close.
Indeed! Cheers, -Barry

On Wed, May 9, 2012 at 10:39 AM, Barry Warsaw <barry@python.org> wrote:
Whoops. I meant that I'm okay with having sys.implementation.version and sys.implementation.lang_version, both as analogs to sys.version_info. My inclination is to not include the analog to sys.version. However, with the way that you put it, I think you're right that we could put off the lang_version attribute for later.
Agreed. -eric
participants (16)
-
"Martin v. Löwis"
-
Antoine Pitrou
-
Barry Warsaw
-
Brett Cannon
-
Eric Snow
-
Georg Brandl
-
Glenn Linderman
-
Jeff Hardy
-
Larry Hastings
-
martin@v.loewis.de
-
Nick Coghlan
-
R. David Murray
-
Scott Dial
-
Steven D'Aprano
-
Terry Reedy
-
Tres Seaver