[Python-Dev] PEP 520: Ordered Class Definition Namespace

[Guido van Rossum]

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
long as it's in their documentation (so users can rely on it in those
cases).

As another point of review, I don't like the exception for dunder names. I
can see that __module__, __name__ etc. are distractions, but since you're
adding methods, you should also add methods with dunder names.

The overlap with PEP 487 makes me think that this feature is clearly
desirable (I like the name you give it in PEP 520 better, and PEP 487 is
too vague about its definition).

Finally, it seems someone is working on making all dicts ordered. Does that
mean this will soon be obsolete?

On Fri, Jun 17, 2016 at 6:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 7 June 2016 at 17:50, Eric Snow <ericsnowcurrently at gmail.com> 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 attribute as the last thing in the body.  However,
> > then independent decorators could only make use of classes that had done
> > so.  Instead, ``__definition_order__`` preserves this one bit of info
> > from the class body so that it is universally available.
>
> 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 addition to defining it for types
> created via the class statement or types.new_class().
>
> For static types, PyType_Ready could potentially set it based on
> tp_members, tp_methods & tp_getset (see
> https://docs.python.org/3/c-api/typeobj.html )
> Similarly, PyType_FromSpec could potentially set it based on the
> contents of Py_tp_members, Py_tp_methods and Py_tp_getset slot
> definitions
>
> Having definition order support in both types.new_class() and builtin
> types would also make it clear why we can't rely purely on the
> compiler to provide the necessary ordering information - in both of
> those cases, the Python compiler isn't directly involved in the type
> creation process.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160620/a1c4018c/attachment-0001.html>