Tuple question

[Alex Martelli]

Donn Cave <donn at drizzle.com> wrote:

> Quoth aleaxit at yahoo.com (Alex Martelli):
> | Donn Cave <donn at u.washington.edu> wrote:
> |    ... 
> |> On the other hand, we normally use tuples for data that
> |> is meaningful only when it's intact.  The (key, value)
> |
> | So by this argument len(t) should not work if t is a tuple...
> 
> I expect it's used relatively infrequently, and for different
> reasons.  "if len(info) == 5", for example - just from that
> line from a relatively popular Python application, would you
> guess info is a list, or a tuple?

No idea -- could just as well be a dict, an array.array, whatever.
That's the very point and the beauty of polymorphism - I don't CARE what
kind of container 'info' is, I know by this snippet that we're testing
if it has exactly 5 items, or not.


> | Even for a pair I sometimes like to know if 42 is the key, the  value,
> | or neither.  index is handy for that... but not if the pair is a tuple,
> | only if it's a list.  Rationalize as you will, it's still a Python wart.
> 
> Maybe the problem is that tuples have too many features already.
> It's sort of silly that they're indexed by number, and if that
> weren't allowed, we would find fewer people trying to make lists
> of them.

Hmmm, how would you access a specific item (since tuples currently don't
support item access by name) if not by indexing?

 
> | Pseudotuples with NAMED (as well as indexed) arguments, as modules stat
> | 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
> | items can't be named, just indexed or sliced, just are not a good fit
> | for the kind of use case you and Guido use to justify tuple's lack of
> | methods, IMHO.
> 
> There you go, they shouldn't be indexed or sliced, that's right!
> Named attributes would be nice, but otherwise you use pattern
> matching (to the extent support in Python --  key, value = item.)
> Makes for more readable code.

Not for sufficiently long tuples.  Take the 9-item tuples that the time
module used to use before they grew names: having to unpack the tuple to
access a single item of it would be exceedingly tedious and heavily
boilerplatey to boot.

Besides, I _do_ need to have immutable sequences that are suitable as
dict keys.  Today, x=tuple(mylist) performs that role admirably.  So,
say I have a dict d, indexed by such tuples -- of different lengths --
and I want all the keys into d that have 23 as their first item.  Today
this is a trivial task -- but if I couldn't index tuples I WOULD have a
problem... basically I would need "frozen lists" (and "frozen dicts"
where I today use tuple(d.iteritems())...).  Today, tuples serve all of
these roles -- poor man's structs (lacking names), immutable 'frozen'
lists for dict-keying roles, etc.  We need at least two new builtin
types to take their place if we want to remove tuple indexing...


Alex