Tuple question

[Alex Martelli]

Andrew Durdin <adurdin at gmail.com> wrote:
   ...
> > and time now return, may be a different issue.  Not sure why we never
> > made declaring such pseudotuples as usertypes as easy as it should be, a
> > custom metaclass in some stdlib module shd be enough.  But tuples whose
   ...
> Such "pseudotuples" are easy enough to implement. Since I'm not all
> that crash hot with metaclasses, I just made a tuple subclass (see
> below). Would a metaclass implementation offer any significant
> benefits over a subclass?

I think of a tuple with a given sequence of names for its fields as a
type (a subclass of tuple, sure).  For example, the name->index
correspondence for all the pseudotuples-with-9-items returned by module
time is just the same one -- why would I want to carry around that
dictionary for each INSTANCE of a time-pseudotuple, rather than having
it once and for all in the type?  So I'd have, say:

example_type = tuple_with_names('foo', 'bar', 'baz')
assert issubclass(example_type, tuple)

and then I could make as many instances of this subclass of tuple as
needed, with a call like either example_type(1,2,3) or
example_type(baz=3,foo=1,bar=2) [the first form would accept 3
positional arguments, the second one 3 named arguments -- they're all
needed of course, but passing them as named will often result in clearer
and more readable application-level code].

You prefer to specify the names every time you make an instance and
build and carry the needed name->index dict along with each instance.
Ah well, I guess that's OK, but I don't really see the advantage
compared to the custom-metaclass approach.

> (Submitted to the Cookbook: recipe #303439)

Great, thanks -- I should get the snapshot tomorrow (or whenever they do
start working again over in Vancouver, since I get it from
ActiveState:-) and I'll be happy to consider presenting your approach
(and a custom metaclass for contrast;-).


Alex