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 probl
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 re
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 def
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 approac
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
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
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
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 mainten
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 co
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 d
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
>>> ev
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; "th
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 exceptio
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-
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
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
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
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 want
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
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 tha
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
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
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 _
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 inclu
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 t
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
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? (
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 plann
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 Ordered
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,
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 2
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 gr
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 prop
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 Ordered
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 d
35 matches
Mail list logo
