Tuple question

[Bengt Richter]

On Sun, 05 Sep 2004 04:39:43 -0000, "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?
>
>| I've never accepted the BDFL's explanations on what tuples are for; like
>| Python beginners I use them as immutable lists (to index into a
>| dictionary or be set members) and curse their lack of useful methods.
>|
>| > pair that comes back from dict.items(), for example.  Each
>| > value may very well be a string, but the sequence is not
>| > homogeneous in the sense we're talking about, and index()
>| > is not useful.
>|
>| 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.
>
>| 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.
>

How about just named read-only but redefinable views? E.g.,

 >>> class TV(tuple):
 ...     """tuple view"""
 ...     _views = {}
 ...     def __getattr__(self, name):
 ...         try: return tuple.__getitem__(self, self.__class__._views[name])
 ...         except KeyError: raise AttributeError, '%s is not a tuple view.' %name
 ...     def __setattr__(self, name, ix):
 ...         self.__class__._views[name] = ix
 ...     def __delattr__(self, name): del self.__class__._views[name]
 ...
 >>> t=TV(range(3,10))
 >>> t
 (3, 4, 5, 6, 7, 8, 9)
 >>> t.a
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 6, in __getattr__
 AttributeError: a is not a tuple view.
 >>> t.a = 3
 >>> t.a
 6
 >>> t.b = slice(4,6)
 >>> t.b
 (7, 8)
 >>> del t.a
 >>> t.a
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "<stdin>", line 6, in __getattr__
 AttributeError: a is not a tuple view.
 >>> t
 (3, 4, 5, 6, 7, 8, 9)
 >>> t.a = slice(None,None,-1)
 >>> t.a
 (9, 8, 7, 6, 5, 4, 3)
 
Of course, with the views in the class's _views dict, further instances share
previous definitions:

 >>> t2 = TV('abcdefg')
 >>> t2
 ('a', 'b', 'c', 'd', 'e', 'f', 'g')
 >>> t2.a
 ('g', 'f', 'e', 'd', 'c', 'b', 'a')
 >>> t2.b
 ('e', 'f')

You could generalize further with properties defining whatever viewing
function you want, of course.

Regards,
Bengt Richter