On 06/07/2016 11:13 AM, Eric Snow wrote:
On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote:
On 06/07/2016 10:51 AM, Eric Snow wrote:
Specification
=
* types for which `__prepare__()`` returned something other than
``OrderedDict`` (or a subclass)
On 07.06.16 20:51, Eric Snow wrote:
Hi all,
Following discussion a few years back (and rough approval from Guido
[1]), I started work on using OrderedDict for the class definition
namespace by default. The bulk of the effort lay in implementing
OrderedDict in C, which I got landed just in time
> On Jun 7, 2016, at 4:12 PM, Nick Coghlan wrote:
>
> By the time decorators run, the original execution namespace is no
> longer available - the contents have been copied into the class dict,
> which will still be a plain dict (and there's a lot of code that calls
>
On Tue, Jun 07, 2016 at 11:39:06AM -0700, Eric Snow wrote:
> On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote:
> > On 6/7/2016 1:51 PM, Eric Snow wrote:
> >
> >> Note: just to be clear, this PEP is *not* about changing
> >
> >> ``type.__dict__`` to ``OrderedDict``.
> >
> > By
On 7 June 2016 at 16:03, Raymond Hettinger wrote:
>
>> On Jun 7, 2016, at 10:51 AM, Eric Snow wrote:
>>
>> This PEP changes the default class definition namespace to ``OrderedDict``.
>
> I think this would be a nice improvement.
>
>>
> On Jun 7, 2016, at 10:51 AM, Eric Snow wrote:
>
> This PEP changes the default class definition namespace to ``OrderedDict``.
I think this would be a nice improvement.
> Furthermore, the order in which the attributes are defined in each class
> body will now be
On 06/07/2016 03:27 PM, Eric Snow wrote:
Not all attrs are writable and it's a case-by-case situation: some of
the ones that are writable started out read-only and changed once
there was a valid reason. If anything, it's arguably safer in general
to take an immutable-by-default approach.
I'm
On Tue, Jun 7, 2016 at 2:34 PM, Ethan Furman wrote:
> On 06/07/2016 02:20 PM, Eric Snow wrote:
>> I think both of those make __definition_order__ more complicated and
>> less useful. As the PEP stands, folks can be confident in what
>> __definition_order__ represents. What
On Tue, Jun 7, 2016 at 2:34 PM, Nick Coghlan wrote:
> On 7 June 2016 at 14:20, Eric Snow wrote:
>> What would you consider to be the
>> benefit of a mutable (or replaceable) __definition_order__ that
>> outweighs the benefit of a simpler
On 7 June 2016 at 14:20, Eric Snow wrote:
> On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote:
>> The main alternative would be to make __definition_order__ writable,
>> so the default behaviour would be for it to reflect the original class
>>
On 06/07/2016 02:20 PM, Eric Snow wrote:
On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote:
On 7 June 2016 at 10:51, Eric Snow wrote:
* ``__definition_order__`` is a tuple
* ``__definition_order__`` is a read-only attribute
Thinking about the class decorator use case, I think this may
On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote:
> On 7 June 2016 at 10:51, Eric Snow wrote:
>> * ``__definition_order__`` is a tuple
>> * ``__definition_order__`` is a read-only attribute
>
> Thinking about the class decorator use case, I
On 7 June 2016 at 10:51, Eric Snow wrote:
> Specification
> =
>
> * the default class *definition* namespace is now ``OrderdDict``
> * the order in which class attributes are defined is preserved in the
> new ``__definition_order__`` attribute on each
> From: Eric Snow
> Sent: Tuesday, June 07, 2016 2:52 PM
> To: Émanuel Barry
> Cc: Python-Dev
> Subject: Re: [Python-Dev] PEP: Ordered Class Definition Namespace
>
> "dunder" names (not just methods) will not be present in
> __definition_order__. I'll add an
On Tue, Jun 7, 2016 at 11:45 AM, Ethan Furman wrote:
> On 06/07/2016 11:13 AM, Eric Snow wrote:
>> A __definition_order__ in the class body always takes precedence. So
>> a supplied value will be honored (and not replaced with None).
>
> Will the supplied __definition_order__
On Tue, Jun 7, 2016 at 11:36 AM, Émanuel Barry wrote:
>> From: Eric Snow
>> * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
>
> What does this imply? If I define some __dunder__ methods, will they simply
> not be present in __definition_order__? What if I
On 06/07/2016 11:13 AM, Eric Snow wrote:
On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote:
On 06/07/2016 10:51 AM, Eric Snow wrote:
Specification
=
* types for which `__prepare__()`` returned something other than
``OrderedDict`` (or a subclass)
On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy wrote:
> On 6/7/2016 1:51 PM, Eric Snow wrote:
>
>> Note: just to be clear, this PEP is *not* about changing
>
>> ``type.__dict__`` to ``OrderedDict``.
>
> By 'type', do you mean the one and one objected named 'type or the class
>
> From: Eric Snow
> Sent: Tuesday, June 07, 2016 1:52 PM
> To: Python-Dev
> Subject: [Python-Dev] PEP: Ordered Class Definition Namespace
>
>
> Currently the namespace used during execution of a class body defaults
> to dict. If the metaclass defines ``__prepa
On 6/7/2016 1:51 PM, Eric Snow wrote:
Note: just to be clear, this PEP is *not* about changing
> ``type.__dict__`` to ``OrderedDict``.
By 'type', do you mean the one and one objected named 'type or the class
being defined? To be really clear, will the following change?
>>> class C: pass
On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote:
> On 06/07/2016 10:51 AM, Eric Snow wrote:
>> Specification
>> =
>
>
>>* types for which `__prepare__()`` returned something other than
>> ``OrderedDict`` (or a subclass) have their
On 06/07/2016 10:51 AM, Eric Snow wrote:
My intention was to land the patch soon, having gone through code
review during PyCon. However, Nick pointed out to me the benefit of
having a concrete point of reference for the change, as well as making
sure it isn't a problem for other
Hi all,
Following discussion a few years back (and rough approval from Guido
[1]), I started work on using OrderedDict for the class definition
namespace by default. The bulk of the effort lay in implementing
OrderedDict in C, which I got landed just in time for 3.5. The
remaining work was
23 matches
Mail list logo