[Python-Dev] Preserving the definition order of class namespaces.
tl;dr Are there any objections to making making the default cls.__prepare__ return OrderedDict instead of dict (and preserve that order in a list on the class)? A couple years ago [1][2] I proposed making class definition namespaces use OrderedDict by default. Said Guido [3]: I'm fine with doing this by default for a class namespace; the type of cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to have 100,000 entries. It turns out making cls.__dict__ an OrderedDict isn't reasonably tractable (due to the concrete API v. subclasses), but really that isn't what I was looking for anyway. Regardless, since it's been a while I just want to run the proposal by the group again. I'm hopeful about landing my C implementation of OrderedDict [4] in the next few days. Also, I have a patch up [5] that implements using OrderedDict for class definitions. So mostly I just want to double check that I'm still good to go. Just to be clear on what I'm proposing specifically, I've summed it up below. -eric - Currently if you want to preserve the order of a class definition you have to use a metaclass with a __prepare__ method (see PEP 3115). However, as that PEP points out [6], the common case for __prepare__ is to use OrderedDict. I'm proposing that we return OrderedDict() by default from __prepare__. Considering the common case, we should also expose that definition order on the class afterward since otherwise the extra information from the class definition namespace is discarded (type.__new__ copies it into a dict which is then used for cls.__dict__). So the key changes are: * use OrderedDict by default for class definition namespace (e.g. from type.__prepare__) * expose that definition order as cls.__definition_order__ (a list) (Note that I will not be changing the actual type of cls.__dict__ (i.e. tp_dict) which will remain a dict.) The effect of the change would be that the following are basically equivalent (relative to the the definition namespace): class Meta(type): @classmethod. def __prepare__(meta, *args, **kwargs): return OrderedDict() class SpamOld(metaclass=Meta): a = 1 b = 2 c = 3 __definition_order__ = list(locals()) class SpamNew: a = 1 b = 2 c = 3 assert SpamOld.__definition__order == SpamNew.__definition_order__ The key differences are: * for SpamNew you don't need to use a metaclass [7][8] * for SpamNew you don't need to rely on the behavior of locals() * for SpamNew the class definition isn't cluttered with extra boilerplate for __definition_order__ * class decorators that care about definition order [9] don't have to require that classes like SpamNew manually preserve that order somehow The patch for the change is pretty minimal. [5] Also, Nick Coghlan recently expressed that he favored using OrderedDict by default over the alternative presented by PEP 422/487. [10] [1] https://mail.python.org/pipermail/python-ideas/2013-February/019690.html [2] https://mail.python.org/pipermail/python-dev/2013-June/127103.html [3] Guido: https://mail.python.org/pipermail/python-ideas/2013-February/019704.html [4] http://bugs.python.org/issue16991 [5] http://bugs.python.org/issue24254 [6] see the "Alternate Proposals" section of https://www.python.org/dev/peps/pep-3115/ [7] PEPs 422 and 487 relatedly focus on the benefits of reducing the need to use metaclasses [8] https://mail.python.org/pipermail/python-ideas/2013-February/019706.html [9] see "Key points" on https://mail.python.org/pipermail/python-dev/2013-February/124439.html [10] Nick: https://mail.python.org/pipermail/python-ideas/2015-March/032254.html ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 24 May 2015 at 11:15, Eric Snow wrote: > tl;dr Are there any objections to making making the default > cls.__prepare__ return OrderedDict instead of dict (and preserve that > order in a list on the class)? > > A couple years ago [1][2] I proposed making class definition > namespaces use OrderedDict by default. Said Guido [3]: > > I'm fine with doing this by default for a class namespace; the type of > cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to > have 100,000 entries. > > It turns out making cls.__dict__ an OrderedDict isn't reasonably > tractable (due to the concrete API v. subclasses), but really that > isn't what I was looking for anyway. > > Regardless, since it's been a while I just want to run the proposal by > the group again. I'm hopeful about landing my C implementation of > OrderedDict [4] in the next few days. Also, I have a patch up [5] > that implements using OrderedDict for class definitions. So mostly I > just want to double check that I'm still good to go. While it isn't controversial (since you already have the +1 from Guido), it's worth writing up the change as a PEP for 3.6 anyway, since that then provides clearer guidance to alternate implementations that they're going to need to change the way their class namespace evaluation works for 3.6. Let's not repeat the zip archive and directory execution mistake that 3.5's PEP 441 aimed to resolve :) PEP 487 could then be updated to reference that PEP as part of the rationale for dropping the "easy namespace customisation" aspect of the proposal. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 24 May 2015 at 12:04, Nick Coghlan wrote: > On 24 May 2015 at 11:15, Eric Snow wrote: >> tl;dr Are there any objections to making making the default >> cls.__prepare__ return OrderedDict instead of dict (and preserve that >> order in a list on the class)? >> >> A couple years ago [1][2] I proposed making class definition >> namespaces use OrderedDict by default. Said Guido [3]: >> >> I'm fine with doing this by default for a class namespace; the type of >> cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to >> have 100,000 entries. >> >> It turns out making cls.__dict__ an OrderedDict isn't reasonably >> tractable (due to the concrete API v. subclasses), but really that >> isn't what I was looking for anyway. >> >> Regardless, since it's been a while I just want to run the proposal by >> the group again. I'm hopeful about landing my C implementation of >> OrderedDict [4] in the next few days. Also, I have a patch up [5] >> that implements using OrderedDict for class definitions. So mostly I >> just want to double check that I'm still good to go. > > While it isn't controversial (since you already have the +1 from > Guido), it's worth writing up the change as a PEP for 3.6 anyway, > since that then provides clearer guidance to alternate implementations > that they're going to need to change the way their class namespace > evaluation works for 3.6. Eric clarified for me that Larry was considering granting a feature freeze exemption to defer landing this to beta 2 while Eric tracked down a segfault bug in the current patch that provides a C implementation of OrderedDict. That sounds like a nicer approach than what I did for PEP 489 (where I checked in an initial version that I knew still had a refleak bug in it), so +1 from me for going down that path. A top level section in the What's New would cover my concerns regarding making sure folks are suitably aware of the change (as I believe leaving it out of the original 2.6 What's New document was the real problem with making people aware of the addition of zip archive and directory execution support). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 05/23/2015 07:38 PM, Nick Coghlan wrote: Eric clarified for me that Larry was considering granting a feature freeze exemption to defer landing this to beta 2 while Eric tracked down a segfault bug in the current patch that provides a C implementation of OrderedDict. Yeah, I'm willing to grant the feature freeze exception, assuming he can find general approval from the community (and assuming he still has Guido's blessing). I just wanted a little more sunlight on the topic, rather than rushing to check it in. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
How will __definition_order__ be set in the case where __prepare__ doesn't return an OrderedDict? Or where a custom metaclass's __new__ calls its superclass's __new__ with a plain dict? (I just wrote some code that does that. :-) On Sat, May 23, 2015 at 7:38 PM, Nick Coghlan wrote: > On 24 May 2015 at 12:04, Nick Coghlan wrote: > > On 24 May 2015 at 11:15, Eric Snow wrote: > >> tl;dr Are there any objections to making making the default > >> cls.__prepare__ return OrderedDict instead of dict (and preserve that > >> order in a list on the class)? > >> > >> A couple years ago [1][2] I proposed making class definition > >> namespaces use OrderedDict by default. Said Guido [3]: > >> > >> I'm fine with doing this by default for a class namespace; the type > of > >> cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely > to > >> have 100,000 entries. > >> > >> It turns out making cls.__dict__ an OrderedDict isn't reasonably > >> tractable (due to the concrete API v. subclasses), but really that > >> isn't what I was looking for anyway. > >> > >> Regardless, since it's been a while I just want to run the proposal by > >> the group again. I'm hopeful about landing my C implementation of > >> OrderedDict [4] in the next few days. Also, I have a patch up [5] > >> that implements using OrderedDict for class definitions. So mostly I > >> just want to double check that I'm still good to go. > > > > While it isn't controversial (since you already have the +1 from > > Guido), it's worth writing up the change as a PEP for 3.6 anyway, > > since that then provides clearer guidance to alternate implementations > > that they're going to need to change the way their class namespace > > evaluation works for 3.6. > > Eric clarified for me that Larry was considering granting a feature > freeze exemption to defer landing this to beta 2 while Eric tracked > down a segfault bug in the current patch that provides a C > implementation of OrderedDict. That sounds like a nicer approach than > what I did for PEP 489 (where I checked in an initial version that I > knew still had a refleak bug in it), so +1 from me for going down that > path. > > A top level section in the What's New would cover my concerns > regarding making sure folks are suitably aware of the change (as I > believe leaving it out of the original 2.6 What's New document was the > real problem with making people aware of the addition of zip archive > and directory execution support). > > Regards, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 05/23/2015 09:46 PM, Guido van Rossum wrote: How will __definition_order__ be set in the case where __prepare__ doesn't return an OrderedDict? Or where a custom metaclass's __new__ calls its superclass's __new__ with a plain dict? (I just wrote some code that does that. :-) In his patch, type_new tests to see if the dict passed in is an ordered dict (PyODict_Check). __definition_order__ is only created and populated if it passes the test. http://bugs.python.org/file39446/odict-class-definition-namespace.diff //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
But isn't that also a problem? It would make the existence of that member a bit unpredictable. On Saturday, May 23, 2015, Larry Hastings wrote: > > > On 05/23/2015 09:46 PM, Guido van Rossum wrote: > > How will __definition_order__ be set in the case where __prepare__ doesn't > return an OrderedDict? Or where a custom metaclass's __new__ calls its > superclass's __new__ with a plain dict? (I just wrote some code that does > that. :-) > > > In his patch, type_new tests to see if the dict passed in is an ordered > dict (PyODict_Check). __definition_order__ is only created and populated > if it passes the test. > > http://bugs.python.org/file39446/odict-class-definition-namespace.diff > > > */arry* > -- --Guido van Rossum (on iPad) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 23, 2015 10:47 PM, "Guido van Rossum" wrote: > > How will __definition_order__ be set in the case where __prepare__ doesn't return an OrderedDict? Or where a custom metaclass's __new__ calls its superclass's __new__ with a plain dict? (I just wrote some code that does that. :-) I was planning on setting it to None if the order is not available. At the moment that's just a check for OrderedDict. -eric > > On Sat, May 23, 2015 at 7:38 PM, Nick Coghlan wrote: >> >> On 24 May 2015 at 12:04, Nick Coghlan wrote: >> > On 24 May 2015 at 11:15, Eric Snow wrote: >> >> tl;dr Are there any objections to making making the default >> >> cls.__prepare__ return OrderedDict instead of dict (and preserve that >> >> order in a list on the class)? >> >> >> >> A couple years ago [1][2] I proposed making class definition >> >> namespaces use OrderedDict by default. Said Guido [3]: >> >> >> >> I'm fine with doing this by default for a class namespace; the type of >> >> cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to >> >> have 100,000 entries. >> >> >> >> It turns out making cls.__dict__ an OrderedDict isn't reasonably >> >> tractable (due to the concrete API v. subclasses), but really that >> >> isn't what I was looking for anyway. >> >> >> >> Regardless, since it's been a while I just want to run the proposal by >> >> the group again. I'm hopeful about landing my C implementation of >> >> OrderedDict [4] in the next few days. Also, I have a patch up [5] >> >> that implements using OrderedDict for class definitions. So mostly I >> >> just want to double check that I'm still good to go. >> > >> > While it isn't controversial (since you already have the +1 from >> > Guido), it's worth writing up the change as a PEP for 3.6 anyway, >> > since that then provides clearer guidance to alternate implementations >> > that they're going to need to change the way their class namespace >> > evaluation works for 3.6. >> >> Eric clarified for me that Larry was considering granting a feature >> freeze exemption to defer landing this to beta 2 while Eric tracked >> down a segfault bug in the current patch that provides a C >> implementation of OrderedDict. That sounds like a nicer approach than >> what I did for PEP 489 (where I checked in an initial version that I >> knew still had a refleak bug in it), so +1 from me for going down that >> path. >> >> A top level section in the What's New would cover my concerns >> regarding making sure folks are suitably aware of the change (as I >> believe leaving it out of the original 2.6 What's New document was the >> real problem with making people aware of the addition of zip archive >> and directory execution support). >> >> Regards, >> Nick. >> >> -- >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > -- > --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 24 May 2015 at 15:53, Eric Snow wrote: > > On May 23, 2015 10:47 PM, "Guido van Rossum" wrote: >> >> How will __definition_order__ be set in the case where __prepare__ doesn't >> return an OrderedDict? Or where a custom metaclass's __new__ calls its >> superclass's __new__ with a plain dict? (I just wrote some code that does >> that. :-) > > I was planning on setting it to None if the order is not available. At the > moment that's just a check for OrderedDict. Is it specifically necessary to save the order by default? Metaclasses would be able to access the ordered namespace in their __new__ method regardless, and for 3.6, I still like the __init_subclass__ hook idea proposed in PEP 487, which includes passing the original namespace to the new hook. So while I'm sold on the value of making class execution namespaces ordered by default, I'm not yet sold on the idea of *remembering* that order without opting in to doing so in the metaclass. If we leave __definition_order__ out for the time being then, for the vast majority of code, the fact that the ephemeral namespace used to evaluate the class body switched from being a basic dictionary to an ordered one would be a hidden implementation detail, rather than making all type objects a little bigger. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 24/05/15 10:35, Nick Coghlan wrote: On 24 May 2015 at 15:53, Eric Snow wrote: On May 23, 2015 10:47 PM, "Guido van Rossum" wrote: How will __definition_order__ be set in the case where __prepare__ doesn't return an OrderedDict? Or where a custom metaclass's __new__ calls its superclass's __new__ with a plain dict? (I just wrote some code that does that. :-) I was planning on setting it to None if the order is not available. At the moment that's just a check for OrderedDict. Is it specifically necessary to save the order by default? Metaclasses would be able to access the ordered namespace in their __new__ method regardless, and for 3.6, I still like the __init_subclass__ hook idea proposed in PEP 487, which includes passing the original namespace to the new hook. So while I'm sold on the value of making class execution namespaces ordered by default, I'm not yet sold on the idea of *remembering* that order without opting in to doing so in the metaclass. If we leave __definition_order__ out for the time being then, for the vast majority of code, the fact that the ephemeral namespace used to evaluate the class body switched from being a basic dictionary to an ordered one would be a hidden implementation detail, rather than making all type objects a little bigger. and a little slower. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 24 May 2015 at 19:44, Mark Shannon wrote: > On 24/05/15 10:35, Nick Coghlan wrote: >> If we leave __definition_order__ out for the time being then, for the >> vast majority of code, the fact that the ephemeral namespace used to >> evaluate the class body switched from being a basic dictionary to an >> ordered one would be a hidden implementation detail, rather than >> making all type objects a little bigger. > and a little slower. The runtime namespace used to store the class attributes is remaining a plain dict object regardless, it's only the ephemeral one that's used to evaluate the class body at definition time that Eric's proposing to switch to an ordered dictionary. That approach avoids any new runtime overhead when using the defined class, while still making the order of attribute assignment available to custom metaclasses by default. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 24, 2015 3:35 AM, "Nick Coghlan" wrote: > Is it specifically necessary to save the order by default? Metaclasses > would be able to access the ordered namespace in their __new__ method > regardless, and for 3.6, I still like the __init_subclass__ hook idea > proposed in PEP 487, which includes passing the original namespace to > the new hook. > > So while I'm sold on the value of making class execution namespaces > ordered by default, I'm not yet sold on the idea of *remembering* that > order without opting in to doing so in the metaclass. > > If we leave __definition_order__ out for the time being then, for the > vast majority of code, the fact that the ephemeral namespace used to > evaluate the class body switched from being a basic dictionary to an > ordered one would be a hidden implementation detail, rather than > making all type objects a little bigger. It's too late for 3.5 to negotiate much so I'll try to make my case here for __definition_order__ one last time. If that's not sufficient then I'll defer further discussion to 3.6. My premise for storing the definition order on the class is that Guido was okay with using OrderedDict for cls.__dict__, which is a bigger change. Regardless, there are two reasons why it makes sense: * If it makes sense to use OrderedDict by default for class definition then it makes sense to preserve the extra information OrderedDict provides. * As I noted at the beginning of the thread, you could still preserve that info manually, but that makes it less convenient for library authors. If you still think that's not enough justification then we can table __definition_order__ for now. -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Sun, May 24, 2015 at 1:36 PM, Eric Snow wrote: > On May 24, 2015 3:35 AM, "Nick Coghlan" wrote: > > Is it specifically necessary to save the order by default? Metaclasses > > would be able to access the ordered namespace in their __new__ method > > regardless, and for 3.6, I still like the __init_subclass__ hook idea > > proposed in PEP 487, which includes passing the original namespace to > > the new hook. > > > > So while I'm sold on the value of making class execution namespaces > > ordered by default, I'm not yet sold on the idea of *remembering* that > > order without opting in to doing so in the metaclass. > > > > If we leave __definition_order__ out for the time being then, for the > > vast majority of code, the fact that the ephemeral namespace used to > > evaluate the class body switched from being a basic dictionary to an > > ordered one would be a hidden implementation detail, rather than > > making all type objects a little bigger. > > It's too late for 3.5 to negotiate much so I'll try to make my case here > for __definition_order__ one last time. If that's not sufficient then > I'll defer further discussion to 3.6. > > My premise for storing the definition order on the class is that Guido was > okay with using OrderedDict for cls.__dict__, which is a bigger change. > Regardless, there are two reasons why it makes sense: > > * If it makes sense to use OrderedDict by default for class definition > then it makes sense to preserve the extra information OrderedDict provides. > * As I noted at the beginning of the thread, you could still preserve that > info manually, but that makes it less convenient for library authors. > > If you still think that's not enough justification then we can table > __definition_order__ for now. > Let's table it. It's hard to compare alternatives on a single dimension of "which is a bigger change". -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 25 May 2015 07:26, "Guido van Rossum" wrote: > > On Sun, May 24, 2015 at 1:36 PM, Eric Snow wrote: >> >> My premise for storing the definition order on the class is that Guido was okay with using OrderedDict for cls.__dict__, which is a bigger change. Regardless, there are two reasons why it makes sense: >> >> * If it makes sense to use OrderedDict by default for class definition then it makes sense to preserve the extra information OrderedDict provides. >> * As I noted at the beginning of the thread, you could still preserve that info manually, but that makes it less convenient for library authors. It occurs to me that even the basic change makes it possible to provide initialisation helpers that accept locals() from a currently running class definition and return a definition ordered list of fields (perhaps restricted to values of a certain type, such as database column definitions, or webform field definitions). >> If you still think that's not enough justification then we can table __definition_order__ for now. > > > Let's table it. It's hard to compare alternatives on a single dimension of "which is a bigger change". Right, it isn't that I think __definition_order__ is necessarily a bad idea, I just suspect it's redundant if we end up going ahead with __init_subclass__ (which would allow a base class to opt in to preserving the definition order, either of all fields or selected ones), and the latter change is definitely out of scope for 3.5 at this point. There are also other open questions, like whether or not dir() should respect the order when reporting attribute names, or if dict_proxy should respect the order when iterating. Regards, Nick. > > -- > --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 24, 2015 4:52 PM, "Nick Coghlan" wrote: > > > On 25 May 2015 07:26, "Guido van Rossum" wrote: > > > > On Sun, May 24, 2015 at 1:36 PM, Eric Snow wrote: > >> If you still think that's not enough justification then we can table __definition_order__ for now. > > > > > > Let's table it. It's hard to compare alternatives on a single dimension of "which is a bigger change". Sounds good. > > Right, it isn't that I think __definition_order__ is necessarily a bad idea, I just suspect it's redundant if we end up going ahead with __init_subclass__ (which would allow a base class to opt in to preserving the definition order, either of all fields or selected ones), > and the latter change is definitely out of scope for 3.5 at this point. > > There are also other open questions, like whether or not dir() should respect the order when reporting attribute names, or if dict_proxy should respect the order when iterating. Yeah, I'll start up a thread on python-ideas once I've gotten the other stuff wrapped up. Thanks for the feedback. -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Sat, 23 May 2015 20:14:56 -0700 Larry Hastings wrote: > > On 05/23/2015 07:38 PM, Nick Coghlan wrote: > > Eric clarified for me that Larry was considering granting a feature > > freeze exemption to defer landing this to beta 2 while Eric tracked > > down a segfault bug in the current patch that provides a C > > implementation of OrderedDict. > > Yeah, I'm willing to grant the feature freeze exception, assuming he can > find general approval from the community (and assuming he still has > Guido's blessing). I just wanted a little more sunlight on the topic, > rather than rushing to check it in. Given the pain that has gone into making the patch segfault- and reference leak-free, and given it adds a lot of complication in the data types area, I'm frankly uneasy with having this land after the feature freeze. It's a sure recipe to *add* instability rather than remove it. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Mon, May 25, 2015, at 03:33, Antoine Pitrou wrote: > On Sat, 23 May 2015 20:14:56 -0700 > Larry Hastings wrote: > > > > On 05/23/2015 07:38 PM, Nick Coghlan wrote: > > > Eric clarified for me that Larry was considering granting a feature > > > freeze exemption to defer landing this to beta 2 while Eric tracked > > > down a segfault bug in the current patch that provides a C > > > implementation of OrderedDict. > > > > Yeah, I'm willing to grant the feature freeze exception, assuming he can > > find general approval from the community (and assuming he still has > > Guido's blessing). I just wanted a little more sunlight on the topic, > > rather than rushing to check it in. > > Given the pain that has gone into making the patch segfault- and > reference leak-free, and given it adds a lot of complication in the > data types area, I'm frankly uneasy with having this land after the > feature freeze. It's a sure recipe to *add* instability rather than > remove it. I agree completely with Antoine. All the hard work that's gone into it recently should make it easy to land stably in 3.6. :) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Mon, May 25, 2015 at 1:33 AM, Antoine Pitrou wrote: > On Sat, 23 May 2015 20:14:56 -0700 > Larry Hastings wrote: >> Yeah, I'm willing to grant the feature freeze exception, assuming he can >> find general approval from the community (and assuming he still has >> Guido's blessing). I just wanted a little more sunlight on the topic, >> rather than rushing to check it in. > > Given the pain that has gone into making the patch segfault- and > reference leak-free, and given it adds a lot of complication in the > data types area, I'm frankly uneasy with having this land after the > feature freeze. It's a sure recipe to *add* instability rather than > remove it. Well, the exception for C OrderedDict itself is a separate matter. I chose to be more public than I could have been about the last remaining bugs in the interest of getting them resolved a bit faster. At this point I wouldn't consider C OrderedDict to add a whole lot of risk to 3.5. That said, at this point landing it in 3.5 it doesn't matter to me much because my main motivator (__definition_order__) isn't landing in 3.5. The fact that 3.6 is already open to new features eases the sting a bit. I'd still prefer to land OrdereDict-by-default class definition namespaces in 3.5, which is dependent on C OrderedDict, but alone that isn't as important to me for 3.5 as cls.__definition_order__ was. Regardless, I know there were a few folks (e.g. Yury) that wanted to see C OrderedDict in 3.5 and there may be others that would really like OrderedDict-by-default in 3.5 (Nick?). Since Larry already gave an exception, I'd still be glad to land both in 3.5 if Yury (or others) wants to make that case. The patches will be ready. -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 2015-05-25 3:40 PM, Eric Snow wrote: I'd still be glad to land both in 3.5 if Yury (or others) wants to make that case. I'm big +1 for a speedy OrderedDict in 3.5 (TBH I thought it was merged in 3.5 long before alpha-4) I doubt that merging it will add such a significant instability that we cannot track and fix in several months before the release, given that all tests pass without refleaks/segfaults before committing the implementation. Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 5/25/2015 3:40 PM, Eric Snow wrote: On Mon, May 25, 2015 at 1:33 AM, Antoine Pitrou wrote: On Sat, 23 May 2015 20:14:56 -0700 Larry Hastings wrote: Yeah, I'm willing to grant the feature freeze exception, assuming he can find general approval from the community (and assuming he still has To me, the message from Antoine, below, and Benjamin's second suggest a lack of 'general approval'. Guido's blessing). I just wanted a little more sunlight on the topic, rather than rushing to check it in. Given the pain that has gone into making the patch segfault- and reference leak-free, and given it adds a lot of complication in the data types area, I'm frankly uneasy with having this land after the feature freeze. It's a sure recipe to *add* instability rather than remove it. Well, the exception for C OrderedDict itself is a separate matter. I chose to be more public than I could have been about the last remaining bugs in the interest of getting them resolved a bit faster. At this point I wouldn't consider C OrderedDict to add a whole lot of risk to 3.5. That said, at this point landing it in 3.5 it doesn't matter to me much because my main motivator (__definition_order__) isn't landing in 3.5. The fact that 3.6 is already open to new features eases the sting a bit. I'd still prefer to land OrdereDict-by-default class definition namespaces in 3.5, which is dependent on C OrderedDict, but alone that isn't as important to me for 3.5 as cls.__definition_order__ was. Regardless, I know there were a few folks (e.g. Yury) that wanted to see C OrderedDict in 3.5 and there may be others that would really like OrderedDict-by-default in 3.5 (Nick?). Since Larry already gave an exception, Conditional on 'general approval of the community'. > I'd still be glad to land both in 3.5 if Yury (or others) wants to make that case. The patches will be ready. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Mon, May 25, 2015 at 2:40 PM, Terry Reedy wrote: > On 5/25/2015 3:40 PM, Eric Snow wrote: >> Since Larry already gave an exception, > > Conditional on 'general approval of the community'. Unless I misunderstood him, Larry gave me an unconditional exception for OrderedDict itself (as long as it is in before beta 2.) The condition only applied to making OrderedDict the default class definition namespace and adding cls.__definition_order__. Furthermore, the condition related to the semantic changes to Python, not to concerns about destabilizing Python. I don't mean to imply that Larry can't retract (or modify) the exceptions he's given me. In fact, if there is sufficient risk of de-stabilizing the release then I'd expect him to do so. However, ultimately that's his call as release manager; and I do not believe there is any greater risk now than what I explained to him in our discussions leading up to the exceptions I received. -eric > >> I'd still be glad to land both in 3.5 if Yury (or >> >> others) wants to make that case. The patches will be ready. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 26 May 2015 05:41, "Eric Snow" wrote: > > Regardless, I know there were a few folks (e.g. Yury) that wanted to > see C OrderedDict in 3.5 and there may be others that would really > like OrderedDict-by-default in 3.5 (Nick?). I think it's the combination with PEP 487 that makes OrderedDict-by-default genuinely compelling, so I don't mind if the application to class namespaces slips to 3.6 (and perhaps even becomes part of that PEP). For the feature freeze exception for the C odict implementation itself, I think I'm morally obliged to back that given my highly debatable decision to check in the PEP 489 implementation even though we hadn't worked out all the kinks in module unloading yet (Petr subsequently got all of the refleaks in the machinery itself sorted out before the beta, including a previously undetected one in PyType_FromSpecAndBases, but there's still a leak when unloading the new multi-phase initialisation test module). Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 05/25/2015 03:22 PM, Eric Snow wrote: On Mon, May 25, 2015 at 2:40 PM, Terry Reedy wrote: On 5/25/2015 3:40 PM, Eric Snow wrote: Since Larry already gave an exception, Conditional on 'general approval of the community'. Unless I misunderstood him, Larry gave me an unconditional exception for OrderedDict itself (as long as it is in before beta 2.) For the record I've granted three exceptions to the beta 1 feature freeze (so far): * Raymond asked for one (a couple weeks ago!) for adding slice support to collections.deque. He knew he wouldn't have time to finish it before beta 1. * Serhiy asked for one very-last-minute for a C reimplementation of lru_cache. He checked it in about a half-hour before feature freeze and it made all the buildbots fail. (The ones that weren't already failing, that is.) * Eric asked for one for this C reimplementation of OrderedDict; the coding was done, the debugging wasn't. And yes, as Eric said, I made separate pronouncements. I said COrderedDict could go in as long as it was in before beta 2; "the other work" of __definition_order__ and switching type_prepare and __build_class__ to using ordered dicts I made conditional on "general approval of the community." The latter has already been tabled for now. So, in all three cases it's work that's been under development for a while. These people did this work out of the kindness of their hearts, to make Python better. As a community we want to encourage that and make sure these developers know we appreciate their efforts. These people would be happier if the work shipped in 3.5 as opposed to 3.6 so it got into user's hands sooner. Also, in Serhiy and Eric's cases, these are reimplementations of existing Python libraries in C. On the one hand, that means we should have good regression test coverage in the library--which it seems like we do, as both of them are debugging problems uncovered by the regression tests. This gives us a little more confidence that the work is good. On the other hand, it does mean there's a higher chance of destabilization, as there's already an installed base using these libraries. (As opposed to something new like math.isclose which has no installed base.) So yes this could introduce bugs that will impact existing users. Bottom line: while an important part job of my job is saying "no", I also feel like an important part of my job is saying "yes". On balance, what will be best for Python? In these cases, I think "yes" is better. My feeling is, let's check it in (before beta 2), and if it causes problems during the betas / rcs we can back them out. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Mon, May 25, 2015 at 6:30 PM, Larry Hastings wrote: > Eric asked for one for this C reimplementation of OrderedDict; the coding > was done, the debugging wasn't. > > And yes, as Eric said, I made separate pronouncements. I said COrderedDict > could go in as long as it was in before beta 2; "the other work" of > __definition_order__ and switching type_prepare and __build_class__ to using > ordered dicts I made conditional on "general approval of the community." > The latter has already been tabled for now. > > > So, in all three cases it's work that's been under development for a while. > These people did this work out of the kindness of their hearts, to make > Python better. As a community we want to encourage that and make sure these > developers know we appreciate their efforts. These people would be happier > if the work shipped in 3.5 as opposed to 3.6 so it got into user's hands > sooner. > > Also, in Serhiy and Eric's cases, these are reimplementations of existing > Python libraries in C. On the one hand, that means we should have good > regression test coverage in the library--which it seems like we do, as both > of them are debugging problems uncovered by the regression tests. This > gives us a little more confidence that the work is good. On the other hand, > it does mean there's a higher chance of destabilization, as there's already > an installed base using these libraries. (As opposed to something new like > math.isclose which has no installed base.) So yes this could introduce bugs > that will impact existing users. > > > Bottom line: while an important part job of my job is saying "no", I also > feel like an important part of my job is saying "yes". On balance, what > will be best for Python? In these cases, I think "yes" is better. My > feeling is, let's check it in (before beta 2), and if it causes problems > during the betas / rcs we can back them out. Thanks, Larry. As to the conditional exceptions, I'm just going to drop those entirely in favor of getting them in 3.6. I'll still pursue OrderedDict for 3.5b2 though (and hope to land it this week). -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote: > On 24 May 2015 at 19:44, Mark Shannon wrote: >> On 24/05/15 10:35, Nick Coghlan wrote: >>> If we leave __definition_order__ out for the time being then, for the >>> vast majority of code, the fact that the ephemeral namespace used to >>> evaluate the class body switched from being a basic dictionary to an >>> ordered one would be a hidden implementation detail, rather than >>> making all type objects a little bigger. >> and a little slower. > The runtime namespace used to store the class attributes is remaining > a plain dict object regardless, Lookup isn't any slower in the ordereddict. Inserts are slower -- and those would happen in the ordereddict, as the type object is being defined. Note that since we're talking about the type objects, rather than the instances, most* long-running code won't care, but it will hurt startup time. *code which creates lots of throwaway classes is obviously an exception. FWIW, much of the extra per-insert cost is driven by either the need to keep deletion O(1) or the desire to keep the C layout binary compatible. A different layout (with its own lookdict) could optimize for the insert-each-value-once case, or even for small dicts (e.g., keyword dicts). I could imagine this producing a speedup, with the ordering being just a side benefit. It is too late to use such a new layout by default in 3.5, but we should be careful not to close it off. (That said, I don't think __definition_order__ would actually close it off, though it might start to look like a wart.) -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Mon, 25 May 2015 17:30:02 -0700 Larry Hastings wrote: > > So, in all three cases it's work that's been under development for a > while. These people did this work out of the kindness of their hearts, > to make Python better. As a community we want to encourage that and > make sure these developers know we appreciate their efforts. These > people would be happier if the work shipped in 3.5 as opposed to 3.6 so > it got into user's hands sooner. I second that sentiment. But it strikes me that we're doing this because our release frequency is completely inadapted. If we had feature releases, say, every 6 or 9 months, the problem wouldn't really exist in the first place. Exceptions granted by the RM only tackle a very small portion of the problem, because the long delay before an accepted patch being in an official release *still* frustrates everyone, and the unpredictability of exceptions only makes things *more* frustrating for most players. Of course, it was pretty much shut down before: https://mail.python.org/pipermail/python-dev/2012-January/115619.html Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 27 May 2015 18:18, "Antoine Pitrou" wrote: > > On Mon, 25 May 2015 17:30:02 -0700 > Larry Hastings wrote: > > > > So, in all three cases it's work that's been under development for a > > while. These people did this work out of the kindness of their hearts, > > to make Python better. As a community we want to encourage that and > > make sure these developers know we appreciate their efforts. These > > people would be happier if the work shipped in 3.5 as opposed to 3.6 so > > it got into user's hands sooner. > > I second that sentiment. But it strikes me that we're doing this > because our release frequency is completely inadapted. If we had > feature releases, say, every 6 or 9 months, the problem wouldn't really > exist in the first place. Exceptions granted by the RM only tackle a > very small portion of the problem, because the long delay before an > accepted patch being in an official release *still* frustrates everyone, > and the unpredictability of exceptions only makes things *more* > frustrating for most players. I'd actually like to pursue a more nuanced view of what's permitted in maintenance releases, based on a combination of the language moratorium PEP, and an approach inspired by PEP 466, requiring that every feature added in a maintenance release be detectable through an attribute check on a module (with corresponding support in dependency checking tools). The problem with simply speeding up the release cycle without constraining the interim releases in some way is that it creates significant pain for alternate implementations and for downstream redistributors (many of whom are still dealing with the fallout of the Python 3 transition). Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Wed, 27 May 2015 18:34:29 +1000 Nick Coghlan wrote: > > I'd actually like to pursue a more nuanced view of what's permitted in > maintenance releases, based on a combination of the language moratorium > PEP, and an approach inspired by PEP 466, requiring that every feature > added in a maintenance release be detectable through an attribute check on > a module (with corresponding support in dependency checking tools). I think this will only complicate the rules and make contributing a specialists' game. Every time you complicate the rules, you add uncertainty, cognitive overhead, opportunities for lengthy discussions, controversies (for an extreme example, think of the Wikipedia process). There is enough boilerplate to care about right now when integrating a patch. > The problem with simply speeding up the release cycle without constraining > the interim releases in some way is that it creates significant pain for > alternate implementations and for downstream redistributors (many of whom > are still dealing with the fallout of the Python 3 transition). At some point, we should recognize our pain is more important than others' when it comes to the fitness of *our* community. I don't see those other people caring about our pain, and proposing e.g. to offload some of the maintenance burden (for example the 2.7 LTS maintenance burden, the maintenance of security branches). For some reason it sounds like we should be altruistic towards people who are not :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 27 May 2015 at 19:02, Antoine Pitrou wrote: > At some point, we should recognize our pain is more important than > others' when it comes to the fitness of *our* community. I don't see > those other people caring about our pain, and proposing e.g. to offload > some of the maintenance burden (for example the 2.7 LTS maintenance > burden, the maintenance of security branches). Sure we care, corporate politics and business cases are just complex beasts to wrangle when it comes to justifying funding of upstream contributions. The main problem I personally have pushing for increased direct upstream investment at the moment is that we're still trying to get folks off Python *2.6*, provide a smoother transition plan for the Python 2.7 network security fixes, and similarly get ready to help customers handle the Python 3 migration, so it's hard for me to make the case that upstream maintenance is the task most in need of immediate investment. (We also don't have a well established culture of Python users reporting Python bugs to the commercial redistributor providing their copy of Python, which breaks one of the key metrics we rely on as redistributors for getting upstream contributions funded appropriately funded: "only files bugs and feature requests directly with the upstream project" and "doesn't use the project at all" unfortunately looks identical from a vendor perspective) Even with those sorts of challenges, Red Hat still covered implementing the extension module importing improvements in 3.5 (as well as making it possible for me to take the time for reviewing the async/await changes, amongst other things), and HP have now taken over from Rackspace as the primary funder of pypi.python.org development (and a lot of PyPA development as well). The Red Hat sponsored CentOS QA infrastructure is also the back end powering the pre-merge patch testing Kushal set up. Red Hat and Canonical have also been major drivers of Python 3 porting efforts for various projects as they've aimed to migrate both Ubuntu and Fedora to using Python 3 as the system Python. Longer term, the best way I know of to get corporations to pick up the tab for things like 2.7 maintenance is to measure it and publish the results (as well as better publicising who is releasing products that depend on it). Paying customers get nervous when open source foundations are publishing contribution metrics that call into question a vendor's ability to support their software (even if the relevant foundation is too polite to point it out explicitly themselves, just making this kind of data available means that competing vendors inevitably use it to snipe at each other). The OpenStack Foundation's stackalytics.openstack.com is a master class in doing this well, with the Linux Foundation's annual kernel development report a close second, so I'd actually like to get the PSF to fund regular contribution metrics for CPython. Setting that up unfortunately hasn't made it to the top of my todo list yet (obviously, given it hasn't been done), but I'm cautiously optimistic about being able to get to it at some point this year. > For some reason it > sounds like we should be altruistic towards people who are not :-) Nope, if we're doing things for the benefit of corporations, we should demand they pay for it if they want it done (or at least be happy that the value of the free software, services and contributions they're making available to the community are sufficient to earn them a fair hearing). However, even if we personally happen to be sceptical of the contributions particular corporations have made to the open source community (or choose to discount any contributions that consist specifically of bug fix commits to the CPython repo), we don't get to ignore their *users* so cavalierly, and we've ended up in a situation where the majority of Python users are 5-7 years behind the progress of core development at this point. Donald's PyPI statistics (https://caremad.io/2015/04/a-year-of-pypi-downloads/) suggest to me that Linux distributions may need to shoulder a lot of the blame for that, and assuming I'm right about that, fixing it involves changing the way Linux distributions work in general, rather than being a Python-specific problem (hence proposals like https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement and new ways of approaching building Linux distributions, like CoreOS and Project Atomic). However, the fact that 2.6 currently still has a larger share of PyPI downloads than Python 3, and that 2.7 is still by far the single most popular version is a problem that we need to be worried about upstream as well. That doesn't point towards "we should make the entire standard library move faster" for me: it points me towards leveraging PyPI to further decouple the rate of evolution of the ecosystem from the rate of evolution of the core interpreter and standard library. If attribute level granularity sounds too complex (a
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 27, 2015, at 06:34 PM, Nick Coghlan wrote: >I'd actually like to pursue a more nuanced view of what's permitted in >maintenance releases, based on a combination of the language moratorium >PEP, and an approach inspired by PEP 466, requiring that every feature >added in a maintenance release be detectable through an attribute check on >a module (with corresponding support in dependency checking tools). PEP 466 and Python 2.7 are a special case. I wouldn't want to adopt such tactics in normal Python 3 releases. Imagine the nightmare of some poor library author who wants to make sure their package works with Python 3.6. They're faced with a source release of 3.6.5, but 3.6.3 in Ubuntu, 3.6.4 in Fedora, 3.6.2 in Debian, and users of all stripes of patch releases on Windows and OS X. Now they have to pepper their code with attribute tests just to support "Python 3.6". In fact, claiming support for Python 3.6 actually doesn't convey enough information to their users. Sure, we can limit this to new features, but even new features introduce risk. We've decided to accept this risk for Python 2.7 for good and important reasons, but we shouldn't do the same for ongoing normal releases. >The problem with simply speeding up the release cycle without constraining >the interim releases in some way is that it creates significant pain for >alternate implementations and for downstream redistributors (many of whom >are still dealing with the fallout of the Python 3 transition). I'm not convinced that relaxing the maintenance release constraints lessens the pain for anybody. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 27, 2015 at 4:18:11 AM, Antoine Pitrou (solip...@pitrou.net) wrote: On Mon, 25 May 2015 17:30:02 -0700 Larry Hastings wrote: > > So, in all three cases it's work that's been under development for a > while. These people did this work out of the kindness of their hearts, > to make Python better. As a community we want to encourage that and > make sure these developers know we appreciate their efforts. These > people would be happier if the work shipped in 3.5 as opposed to 3.6 so > it got into user's hands sooner. I second that sentiment. But it strikes me that we're doing this because our release frequency is completely inadapted. If we had feature releases, say, every 6 or 9 months, the problem wouldn't really exist in the first place. Exceptions granted by the RM only tackle a very small portion of the problem, because the long delay before an accepted patch being in an official release *still* frustrates everyone, and the unpredictability of exceptions only makes things *more* frustrating for most players. Of course, it was pretty much shut down before: https://mail.python.org/pipermail/python-dev/2012-January/115619.html Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io I’m in favor of releasing more often as well. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 27, 2015 at 10:32:47 AM, Barry Warsaw (ba...@python.org) wrote: > On May 27, 2015, at 06:34 PM, Nick Coghlan wrote: > > >I'd actually like to pursue a more nuanced view of what's permitted in > >maintenance releases, based on a combination of the language moratorium > >PEP, and an approach inspired by PEP 466, requiring that every feature > >added in a maintenance release be detectable through an attribute check on > >a module (with corresponding support in dependency checking tools). > > PEP 466 and Python 2.7 are a special case. I wouldn't want to adopt such > tactics in normal Python 3 releases. > > Imagine the nightmare of some poor library author who wants to make sure their > package works with Python 3.6. They're faced with a source release of 3.6.5, > but 3.6.3 in Ubuntu, 3.6.4 in Fedora, 3.6.2 in Debian, and users of all > stripes of patch releases on Windows and OS X. Now they have to pepper their > code with attribute tests just to support "Python 3.6". In fact, claiming > support for Python 3.6 actually doesn't convey enough information to their > users. > > Sure, we can limit this to new features, but even new features introduce risk. > We've decided to accept this risk for Python 2.7 for good and important > reasons, but we shouldn't do the same for ongoing normal releases. > > >The problem with simply speeding up the release cycle without constraining > >the interim releases in some way is that it creates significant pain for > >alternate implementations and for downstream redistributors (many of whom > >are still dealing with the fallout of the Python 3 transition). > > I'm not convinced that relaxing the maintenance release constraints lessens > the pain for anybody. > > Cheers, > -Barry > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io > I think it increases the pain for everyone TBH. I find the backport we did to Python 2.7 pretty crummy, but I think the only thing worse than backporting to a random patch release of 2.7 was not making it available to the 2.x line at all. I think that it would have been better to release it as a 2.8, however that was a hill I felt like dying on personally. Going forward I think we should either stick to the slower release schedule and just say it is what it is or release more often. The inbetween is killer. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
Antoine Pitrou writes: > For some reason it sounds like we should be altruistic towards > people who are not :-) There's always a question of how far to go, of course, but one of the things I like about this community is the attention the developers give to others' pain. In that sense, I'm definitely +1 on altruism. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 5/27/2015 4:16 AM, Antoine Pitrou wrote: I second that sentiment. But it strikes me that we're doing this because our release frequency is completely inadapted. If we had feature releases, say, every 6 or 9 months, the problem wouldn't really exist in the first place. How about a feature release once a year, on a schedule we choose as best for us. For instance, aim for end of May, with a bugfix release and alpha of the next version mid to late Sept after summer vacations. Encourage linux distributions to include the new version in their fall and spring releases. Features that miss a beta1 deadline would then be available to early adopters 4 months later. In general, I think alpha releases have usually been about as good as bugfix releases. High test coverage and green buildbots help. With more frequent releases, there should be fewer major new features and perhaps fewer alpha and beta releases needed. Exceptions granted by the RM only tackle a very small portion of the problem, because the long delay before an accepted patch being in an official release *still* frustrates everyone, and the unpredictability of exceptions only makes things *more* frustrating for most players. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Wed, 27 May 2015 17:15:39 -0400 Terry Reedy wrote: > On 5/27/2015 4:16 AM, Antoine Pitrou wrote: > > > I second that sentiment. But it strikes me that we're doing this > > because our release frequency is completely inadapted. If we had > > feature releases, say, every 6 or 9 months, the problem wouldn't really > > exist in the first place. > > How about a feature release once a year, on a schedule we choose as best > for us. For instance, aim for end of May, with a bugfix release and > alpha of the next version mid to late Sept after summer vacations. > Encourage linux distributions to include the new version in their fall > and spring releases. > > Features that miss a beta1 deadline would then be available to early > adopters 4 months later. In general, I think alpha releases have > usually been about as good as bugfix releases. I don't believe alpha releases are attractive for most users. People don't want to risk losing time over bugs that may be caused by regressions in Python. Regardless of their *actual* stability or quality, releases labelled "alpha" are perceived as high-risk. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
