>>
>> Finally, it seems someone is working on making all dicts ordered. Does that
>> mean this will soon be obsolete?
>
> Nope. Having an ordered definition namespace by default does not give
> us __definition_order__ for free. Furthermore, the compact dict under
> consideration isn't strictly or
On Mon, Jun 20, 2016 at 9:49 AM, Guido van Rossum wrote:
> I agree it's better to define the order as computed at runtime. I don't
> think there's much of a point to mandate that all builtin/extension types
> reveal their order too -- I doubt there will be many uses for that -- but I
> don't want
On Fri, Jun 17, 2016 at 7:32 PM, Nick Coghlan wrote:
> The discussion in the PEP 487 thread made me realise that I'd like to
> see a discussion in PEP 520 regarding whether or not to define
> __definition_order__ for builtin types initialised via PyType_Ready or
> created via PyType_FromSpec in ad
I agree it's better to define the order as computed at runtime. I don't
think there's much of a point to mandate that all builtin/extension types
reveal their order too -- I doubt there will be many uses for that -- but I
don't want to disallow it either. But we can allow types to define this, as
l
On 7 June 2016 at 17:50, Eric Snow wrote:
> Why is __definition_order__ even necessary?
> ---
>
> Since the definition order is not preserved in ``__dict__``, it would be
> lost once class definition execution completes. Classes *could*
> explicitly set the
On Thu, Jun 16, 2016 at 5:11 AM, Nikita Nemkin wrote:
> I'll reformulate my argument:
>
> Ordered class namespaces are a minority use case that's already covered
> by existing language features (custom metaclasses) and doesn't warrant
> the extension of the language (i.e. making OrderedDict a buil
Thanks for raising these good points, Nikita. I'll make sure the PEP
reflects this discussion. (inline responses below...)
-eric
On Tue, Jun 14, 2016 at 3:41 AM, Nikita Nemkin wrote:
> Is there any rationale for rejecting alternatives like:
>
> 1. Adding standard metaclass with ordered namespa
I'll reformulate my argument:
Ordered class namespaces are a minority use case that's already covered
by existing language features (custom metaclasses) and doesn't warrant
the extension of the language (i.e. making OrderedDict a builtin type).
This is about Python-the-Language, not CPython-the-ru
On 14 June 2016 at 02:41, Nikita Nemkin wrote:
> Is there any rationale for rejecting alternatives like:
Good questions - Eric, it's likely worth capturing answers to these in
the PEP for the benefit of future readers.
> 1. Adding standard metaclass with ordered namespace.
Adding metaclasses to
Is there any rationale for rejecting alternatives like:
1. Adding standard metaclass with ordered namespace.
2. Adding `namespace` or `ordered` args to the default metaclass.
3. Making compiler fill in __definition_order__ for every class
(just like __qualname__) without touching the runtime.
On Sun, Jun 12, 2016 at 5:37 AM, Eric Snow wrote:
> The following code demonstrates roughly equivalent semantics for the
> default behavior::
>
>class Meta(type):
>def __prepare__(cls, *args, **kwargs):
Shouldn't this be wrapped with a classmethod decorator?
+1 from me.
--Berker
___
> From: Eric Snow
> Sent: Saturday, June 11, 2016 11:02 PM
> To: Émanuel Barry
> Cc: Python-Dev
> Subject: Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace
> (round 3)
>
> On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry wrote:
> >> From: Eric Snow
&g
On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry wrote:
>> From: Eric Snow
>> 1. if ``__definition_order__`` is defined in the class body then it
>> must be a ``tuple`` of identifiers or ``None``; any other value
>> will result in ``TypeError``
>
> Why not just any arbitrary iterable, wh
> From: Eric Snow
> Sent: Saturday, June 11, 2016 10:37 PM
> To: Python-Dev; Guido van Rossum
> Subject: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round
> 3)
> The only change to the original proposal
> has been that a manually set __definition_order
I've updated the PEP to reflect feedback up to this point. The
reception has been positive. The only change to the original proposal
has been that a manually set __definition_order__ must be a tuple of
identifiers or None (rather that using the value as-is). All other
updates to the PEP have bee
On Fri, Jun 10, 2016 at 11:29 AM, Nick Coghlan wrote:
> On 10 June 2016 at 09:42, Eric Snow wrote:
>> On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan wrote:
>>> That restriction would be comparable to what we do with __slots__ today:
>>>
>>> >>> class C:
>>> ... __slots__ = 1
>>> ..
On 10 June 2016 at 09:42, Eric Snow wrote:
> On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan wrote:
>> That restriction would be comparable to what we do with __slots__ today:
>>
>> >>> class C:
>> ... __slots__ = 1
>> ...
>> Traceback (most recent call last):
>> File "", li
On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan wrote:
> I'm guessing Ethan is suggesting defining it as:
>
> __definition_order__ = tuple(ns["__definition_order__"])
>
> When the attribute is present in the method body.
Ah. I'd rather stick to "consenting adults" in the case that
__definition_
On 06/09/2016 02:39 PM, Nick Coghlan wrote:
On 7 June 2016 at 20:17, Eric Snow wrote:
On Tue, Jun 7, 2016 at 6:20 PM, Ethan Furman wrote:
If __definition_order__ is supposed to be immutable as well as read-only
then we should convert non-tuples to tuples. No point in letting that
user bug sl
On 7 June 2016 at 20:17, Eric Snow wrote:
> On Tue, Jun 7, 2016 at 6:20 PM, Ethan Furman wrote:
>> If __definition_order__ is supposed to be immutable as well as read-only
>> then we should convert non-tuples to tuples. No point in letting that
>> user bug slip through.
>
> Do you mean if a clas
On 6/8/2016 4:07 AM, Victor Stinner wrote:
Abstract
This PEP changes the default class definition namespace to ``OrderedDict``.
Furthermore, the order in which the attributes are defined in each class
body will now be preserved in ``type.__definition_order__``. This allows
introspectio
On Wed, Jun 8, 2016 at 1:07 AM, Victor Stinner wrote:
>> Abstract
>>
>>
>> This PEP changes the default class definition namespace to ``OrderedDict``.
>> Furthermore, the order in which the attributes are defined in each class
>> body will now be preserved in ``type.__definition_order__``
On Wed, Jun 8, 2016 at 12:07 AM, Franklin? Lee
wrote:
> On Jun 7, 2016 8:52 PM, "Eric Snow" wrote:
>> * the default class *definition* namespace is now ``OrderdDict``
>> * the order in which class attributes are defined is preserved in the
>
> By using an OrderedDict, names are ordered by first d
> Abstract
>
>
> This PEP changes the default class definition namespace to ``OrderedDict``.
> Furthermore, the order in which the attributes are defined in each class
> body will now be preserved in ``type.__definition_order__``. This allows
> introspection of the original definition ord
On Jun 7, 2016 8:52 PM, "Eric Snow" wrote:
> * the default class *definition* namespace is now ``OrderdDict``
> * the order in which class attributes are defined is preserved in the
By using an OrderedDict, names are ordered by first definition point,
rather than location of the used definition.
On Tue, Jun 7, 2016 at 6:20 PM, Ethan Furman wrote:
> On 06/07/2016 05:50 PM, Eric Snow wrote:
>> __definition_order__ = tuple(k for k in locals()
>> if (!k.startswith('__') or
>> !k.endswith('__')))
>
>
> Still
On 06/07/2016 05:50 PM, Eric Snow wrote:
Overall +1. Some nits below.
Specification
=
3. types for which `__prepare__()`` returned something other than
``OrderedDict`` (or a subclass) have their ``__definition_order__``
set to ``None``
(unless ``__defini
I've grabbed a PEP # (520) and updated the PEP to clarify points that
were brought up earlier today. Given positive feedback I got at PyCon
and the reaction today, I'm hopeful the PEP isn't far off from
pronouncement. :)
-eric
==
PEP: 520
Title: Ordered C
28 matches
Mail list logo
