[Python-ideas] namedtuple baseclass

[Yury Selivanov]

Steven,

On Sun, Jan 12, 2014 at 6:55 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sun, Jan 12, 2014 at 10:46:51PM +1100, Chris Angelico wrote:
>> On Sun, Jan 12, 2014 at 10:43 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> > It's a tuple. It already uses __getitem__ to return items indexed by
>> > position. Adding magic so that obj["fields"] is an alias for
>> > obj._fields is, well, horrible.
>>
>> It's only an alias in the simple version that I did there. If it were
>> to be used as a means of avoiding the _fields reserved name, it
>> wouldn't be an alias. But yes, it is somewhat magical. I was hunting
>> for an out-of-band way to get that sort of information.
>
> I still don't get how you think this solves the problem that the OP's
> use-case is to use isinstance() to identify namedtuples, then read
> _fields. But with the (proposed, not implemented) namedtuple ABC,
> isinstance(o, NamedTuple) could be true and o._fields fail.

If we decide to implement an ABC, then any class that satisfies it
should implement '_fields' (and _make, and other namedtuple public
methods) properly (this can be enforced in the ABC's '__subclasshook__')

> Breaking
> backwards compatibility to write that as o["fields"] instead won't help,
> because it will still fail:
>
> py> t = os.stat_result([1]*10)
> py> t["fields"]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: tuple indices must be integers, not str
>
>
> Changing namedtuple is not enough.
>
> Oh, and this is a backwards-compatibility breaking change, because
> _fields is part of the *public* API for namedtuple, despite the leading
> underscore.
>
> So I fail to see how anything short of a massive re-engineering of not
> just namedtuple but also any C namedtuple-like types will satisfy the
> OP's use-case. Have I missed something?

If we go with the ABC route, then we can simply implement '_fields' and
other namedtuple methods for the low-level C structure os.stat_results
is using later. But for now, stat_result is not a namedtuple (lacks all
of namedtuple API). So I'm not sure that C namedtuple-like types
should hold us bask on this proposal.

BTW, ABC proposal aside: the current namedtuple implementation
creates the class from a template with "exec" call. For every namedtuple,
it's entire set of methods is created over and over again. Even for the
memory efficiency sake, having a base class with *some* of the common
methods (which are currently in the template) is better.

-
Yury