On Apr 25, 2012, at 11:31 PM, Eric Snow wrote:

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?

It's somewhat of a corner case, but I think a PEP couldn't hurt. The rationale section would be useful, at least. -Barry

On 04/25/2012 10:31 PM, Eric Snow wrote:

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.

My one bit of bike-shedding: I don't think it's desirable that this object be iterable. Therefore I suggest you don't use struct sequence. //arry/

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw 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 Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman wrote:

On 4/27/2012 12:34 AM, Eric Snow wrote:

...

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw 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

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.

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 Sat, Apr 28, 2012 at 6:11 AM, Glenn Linderman wrote:

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?

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 Tue, May 8, 2012 at 7:14 PM, Barry Warsaw wrote:

Hi Eric,

Great job on the latest PEP 421.  I really like it.

Encouragement appreciated. :)

 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.

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.

 * 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.

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.

 * 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."

That's an important distinction. I'll clean it up.

 * 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.)

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 Wed, May 9, 2012 at 5:57 AM, "Martin v. Löwis" wrote:

On 27.04.2012 09:34, Eric Snow wrote:

...

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw 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.htmlhttp://mail.python.org/pipermail/python-ideas/2012-April/014954.html

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.

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 wish there was a builtin class

class record: pass

which can be used to create objects which have only attributes and no methods.

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

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

______________________________**_________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** brett%40python.orghttp://mail.python.org/mailman/options/python-dev/brett%40python.org

On Wed, May 9, 2012 at 3:57 AM, "Martin v. Löwis" wrote:

Interesting proposal. I have a number of comments:

Thanks for taking a look, Martin.

- 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"]

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.

- 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.

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

On Wed, May 9, 2012 at 8:50 AM, Antoine Pitrou wrote:

On Wed, 9 May 2012 10:44:59 -0400 Brett Cannon wrote:

...

...

I wish there was a builtin class

    class record:        pass

  which can be used to create objects which have only attributes   and no methods.

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?

In this case, it's because sys is a built-in module written in C, and importing Python code is a no-go.

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 May 08, 2012, at 09:03 PM, Eric Snow wrote:

...

  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.

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.

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.

...

 * 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.)

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.

Cool. As I said, I'm on the fence about it too. :)

...

 * 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.

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.

...

 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.

Cool.

Thanks for the feedback, Barry! Feels like the PEP's getting close.

Indeed! Cheers, -Barry

On May 09, 2012, at 08:51 AM, Eric Snow wrote:

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.

Right. See my previous follow up for what I think the PEP should say about the semantics of the type, without being so specific about the actual type. Cheers, -Barry

On Wed, May 9, 2012 at 10:39 AM, Barry Warsaw wrote:

On May 08, 2012, at 09:03 PM, Eric Snow wrote:

...

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.

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.

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.

...

...

 * 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.

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.

Agreed. -eric

On Thu, May 10, 2012 at 2:53 AM, Barry Warsaw wrote:

On May 09, 2012, at 11:09 AM, Brett Cannon wrote:

...

Sure, but couldn't we define this "empty" class in C code so that you can use the C API with it as well and just provide a C function to get a new instance?

+1

ISTM to be a companion to collections.namedtuple.  IWBNI this new type was also exposed in the collections module.

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 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".

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).

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.

Nice.

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

Sounds good to me regardless of the PEP. -eric

On Thu, May 10, 2012 at 3:34 PM, "Martin v. Löwis" wrote:

...

We've been over this before: collections.namedtuple *is* the standard library's answer for structured records.

And I think it's a really ugly answer, and one that deserves a parallel that is not a tuple. If this is contentious, I'll write a PEP.

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 Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou wrote:

On Thu, 10 May 2012 11:33:14 +1000 Nick Coghlan wrote:

...

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.

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.

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

On 5/10/2012 10:42 AM, Georg Brandl wrote:

On 10.05.2012 10:57, Antoine Pitrou wrote:

...

On Thu, 10 May 2012 11:33:14 +1000 Nick Coghlan wrote:

...

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.

Uh. It's scary the kind of things people sometimes come up with :-)

.oO( Namespaception )

...

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.

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:

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.

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

Scott Dial wrote:

On 5/10/2012 1:40 AM, Nick Coghlan wrote:

...

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".

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).

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, May 10, 2012 at 3:39 PM, Steven D'Aprano 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.

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.

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

On Thu, May 10, 2012 at 2:57 AM, Antoine Pitrou wrote:

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.

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 May 12, 2012, at 10:04 PM, Nick Coghlan wrote:

On Sat, May 12, 2012 at 12:40 PM, Eric Snow wrote: > 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.

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.

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

On Sat, May 12, 2012 at 6:04 AM, Nick Coghlan wrote:

On Sat, May 12, 2012 at 12:40 PM, Eric Snow wrote:

...

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.

I object to adding a new type to the stdlib just for this PEP.

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.

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:

...

...

...

data = dict(a=1, b=2, c=3) ns = type('', (), data) ns.a 1 ns.b 2 ns.c 3

That's pretty cool. As a counter example, given a normal (dict-based) object you can use vars() to turn it into a dict:

...

...

data = SomeClass(a=1, b=2, c=3) ns = vars(data) ns['a'] 1 ns['b'] 2 ns['c'] 3

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

On Sat, May 12, 2012 at 10:51 AM, Tres Seaver wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 05/12/2012 08:04 AM, Nick Coghlan wrote:

...

On Sat, May 12, 2012 at 12:40 PM, Eric Snow wrote:

...

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.

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.

Why would anyone want to iterate over either of them?

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

On 5/12/2012 10:50 AM, Eric Snow wrote:

given a normal (dict-based) object you can use vars() to turn it into a dict:

...

...

...

...

...

> data = SomeClass(a=1, b=2, c=3) > ns = vars(data) > ns['a'] 1 > ns['b'] 2 > ns['c'] 3

I'll grant that it doesn't work for some objects (like named tuples),

Why not? Seems like it could, with a tweak to vars ... named tuples already have a method to return a dict. vars already has a special case to act like locals. So why not add a special case to allow vars to work on named tuples?

On May 15, 2012, at 10:26 AM, Eric Snow wrote:

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.

It looks great to me. If I were the PEP czar <wink>, I'd approve it. -Barry