[Python-Dev] Classes with ordered namespaces

[Nick Coghlan]

On 28 Jun 2013 07:51, "Eric Snow" <ericsnowcurrently at gmail.com> wrote:
>
> On Thu, Jun 27, 2013 at 9:35 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> > On 06/27/2013 08:18 AM, Eric Snow wrote:
> >> Good points.  In either case there is no definition order available.
> >> I'm okay with that.  Would it be better to represent that as None (and
> >> the attribute is always defined) or by having the attribute undefined?
> >> I'd rather always have the attribute, but I expect the significantly
> >> simpler solution is to leave the attribute undefined when definition
> >> order is not available.  So I'd go with the latter.
> >
> >
> > So in Python space the options are either:
> >
> >    if some_class.__definition_order__ is not None:
> >
> > or
> >
> >    if getattr(some_class, '__definition_order__', None) is not None:
> >
> > ?
> >
> > Seems like always defined would be easier.
>
> Certainly it's easier to use if you need the definition order.
> However, I expect it wouldn't be used often enough that that would
> make a big difference.  Furthermore, if it's always there then it will
> always show up when you dir(SomeClass) or look at SomeClass.__dict__.
> People would see that on every class, whether it actually provided
> definition order or not.  I'm not sure that is as helpful as only
> having the attribute around when order is defined.
>
> This got me thinking.  The attribute should be a class-only attribute
> (i.e. a property on type) like __name__ is.  That would keep it from
> showing up on instance lookups and on every vars(obj).
>
> The big thing for me, though, is that optionally having the attribute
> accommodates Python implementations that can't (or don't) preserve
> definition order.  They don't have to worry about adding a dummy
> attribute to every class just for the sake of complying with the spec.
>  It also means the implementation for dynamic types like Nick
> mentioned don't necesarily need to be touched.  The more I think about
> it the more the optionally set attribute approach is the way to go.

My experience with maybe set, maybe not attributes for modules is that
they're *always* a PITA to deal with and just not worth the hassle.

Better to just expose it as a read-only attribute on class objects (that
isn't accessible through instances) and set it to None on construction if
order info is not available. This will also block accidental inheritance of
the attribute from an ordered base class.

A new keyword-only argument for the dynamic type construction APIs in the
"types" module would also be appropriate, and would allow the creation of
ordered classes even if the implementation used unordered namespaces for
class syntax.

Cheers,
Nick.

>
> -eric
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130628/9abeaac1/attachment.html>