On Fri, Jun 24, 2016 at 3:46 PM, Eric Snow <ericsnowcurren...@gmail.com> wrote:
> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > This version looks fine to me. > > \o/ > Same to me, mostly. > > The definition order question has been dropped from PEP 487, so this > > cross-reference doesn't really make sense any more :) > > Ah, so much for my appeal to authority. <wink> > > > I'd characterise this section at the language definition level as the > > default class definition namespace now being *permitted* to be an > > OrderedDict. For implementations where dict is ordered by default, > > there's no requirement to switch specifically to > > collections.OrderedDict. > > Yeah, I'd meant to fix that. > Please do. > > This paragraph is a little confusing, since "set > > ``__definition_order__`` manually" is ambiguous. > > > > "supply an explicit ``__definition_order__`` via the class namespace" > > might be clearer. > > ack > > > I realised there's another important reason for doing it this way by > > default: it's *really easy* to write a "skip_dunder_names" filter that > > leaves out dunder names from an arbitrary interable of strings. It's > > flatout *impossible* to restore the dunder attribute order if the > > class definition process throws it away. > > Yep. That's why I felt fine with relaxing that. I guess I didn't > actually put that in the PEP though. :) > Please add it. I'd also like the PEP point out that there might be other things that an app wouldn't want in the definition order, e.g. anything that's a method, or anything that starts with '_', etc. I still think that it should not be read-only. If __slots__ and __name__ can be writable I think __definition_order__ can be too. (I believe an easy way to make it so should be to add it to the dict that's passed to type.__new__().) Other nits: - I don't think it's great to let other implementations leave __definition_order__ set to None when they don't care to support it; this would break apps/libraries that want to use it and the implementation could refuse to fix it, claiming PEP 520 doesn't mandate it. I think it's better to mandate this from a confirming implementation. - I don't think there's much of a use case for setting __definition_order__ (to a tuple) for builtin classes. However I do think extension modules should be allowed to set it, in case they are substituting for a previous Python-level class whose users expect this to work. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
