On Mon, 25 May 2015 17:30:02 -0700
Larry Hastings la...@hastings.org 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
On 27 May 2015 18:18, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 25 May 2015 17:30:02 -0700
Larry Hastings la...@hastings.org 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
On Wed, 27 May 2015 18:34:29 +1000
Nick Coghlan ncogh...@gmail.com 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
On 27 May 2015 at 19:02, Antoine Pitrou solip...@pitrou.net 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
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
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
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 la...@hastings.org 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
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
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
On Wed, 27 May 2015 17:15:39 -0400
Terry Reedy tjre...@udel.edu 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,
On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote:
On 24 May 2015 at 19:44, Mark Shannon mark at hotpy.org 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
On Sat, 23 May 2015 20:14:56 -0700
Larry Hastings la...@hastings.org 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
On Mon, May 25, 2015, at 03:33, Antoine Pitrou wrote:
On Sat, 23 May 2015 20:14:56 -0700
Larry Hastings la...@hastings.org 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
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
On 5/25/2015 3:40 PM, Eric Snow wrote:
On Mon, May 25, 2015 at 1:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 May 2015 20:14:56 -0700
Larry Hastings la...@hastings.org wrote:
Yeah, I'm willing to grant the feature freeze exception, assuming he can
find general approval from the
On Mon, May 25, 2015 at 1:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 May 2015 20:14:56 -0700
Larry Hastings la...@hastings.org 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
On 05/25/2015 03:22 PM, Eric Snow wrote:
On Mon, May 25, 2015 at 2:40 PM, Terry Reedy tjre...@udel.edu 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
On Mon, May 25, 2015 at 6:30 PM, Larry Hastings la...@hastings.org 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
On 26 May 2015 05:41, Eric Snow ericsnowcurren...@gmail.com 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
On Mon, May 25, 2015 at 2:40 PM, Terry Reedy tjre...@udel.edu 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
On 24 May 2015 at 19:44, Mark Shannon m...@hotpy.org 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
On 24/05/15 10:35, Nick Coghlan wrote:
On 24 May 2015 at 15:53, Eric Snow ericsnowcurren...@gmail.com wrote:
On May 23, 2015 10:47 PM, Guido van Rossum gu...@python.org wrote:
How will __definition_order__ be set in the case where __prepare__ doesn't
return an OrderedDict? Or where a
On 24 May 2015 at 15:53, Eric Snow ericsnowcurren...@gmail.com wrote:
On May 23, 2015 10:47 PM, Guido van Rossum gu...@python.org 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
On May 24, 2015 3:35 AM, Nick Coghlan ncogh...@gmail.com 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
On 25 May 2015 07:26, Guido van Rossum gu...@python.org wrote:
On Sun, May 24, 2015 at 1:36 PM, Eric Snow ericsnowcurren...@gmail.com
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.
On May 24, 2015 4:52 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 25 May 2015 07:26, Guido van Rossum gu...@python.org wrote:
On Sun, May 24, 2015 at 1:36 PM, Eric Snow ericsnowcurren...@gmail.com
wrote:
If you still think that's not enough justification then we can table
On Sun, May 24, 2015 at 1:36 PM, Eric Snow ericsnowcurren...@gmail.com
wrote:
On May 24, 2015 3:35 AM, Nick Coghlan ncogh...@gmail.com wrote:
Is it specifically necessary to save the order by default? Metaclasses
would be able to access the ordered namespace in their __new__ method
On May 23, 2015 10:47 PM, Guido van Rossum gu...@python.org 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. :-)
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
On 24 May 2015 at 11:15, Eric Snow ericsnowcurren...@gmail.com 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
On 24 May 2015 at 12:04, Nick Coghlan ncogh...@gmail.com wrote:
On 24 May 2015 at 11:15, Eric Snow ericsnowcurren...@gmail.com 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)?
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
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
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 ncogh...@gmail.com
34 matches
Mail list logo
