Tuples, what are they: read-only lists or heterogeneous data arrays?

[Alex Martelli]

On Thursday 13 March 2003 10:29 am, Thomas Wouters wrote:
   ...
> "Wait, I need to use an unwieldy large list/tuple as a dict key, but I also
> want to count/index it... Do I really want the whole list as the dict key,
> or just a few key elements ? What if I add elements later ?" and depending

Exactly the kinds of questions that Python lets me *AVOID* for most
other similar design situations.  Python is mostly set up to encourage
avoidance of the "big design up front" fallacy -- wasting a lot of time
to determine how you may/will use something as development proceeds.


> changes, but could of course be added to the stdlib. If you want a
> 'frozen-copy' protocol for mutable objects, there's only one way to get it:
> start work on it.

Wrong!  My experience tells me that's definitely NOT the way to get
changes into Python -- you work your ass off, then Guido rejects your
work.  Putting about ideas for change, and hoping Guido picks them up
and convinces himself they're HIS ideas, is by far more productive,
whether you then do some of the detailed implementation work yourself
(often advisable, because if nobody does the work then of course the
change doesn't get into Python).

For example, when I first met Python in 1999 I posted a few ideas I
had about enhancements which I'd love to get into Python.  One did
happen to coincide with an idea which Guido DID already have -- a
special method __contains__ to let you overload tests such as
"if x in y:" (I even proposed the same magic name he already had
in mind).  Another was "new and revolutionary":

"""
Regarding the
    for a in X:
case, the point is that I can well have a class X [...] where I can easily 
get the "next" item, but not the "N-th item" for arbitrary N without a 
large amount of work.
   ...
The way I envision this -- if X chooses to implement a method __enum__, 
then, that method must return an object which implements methods 
such as __current__ (returning the current element in the iteration) and 
__advance__ (returning false if at end, else stepping forward) --
"""

In this case, the method ended up being named __iter__ instead of
__enum__ as I had proposed, and the returned object implements a
single method with a non-magic name 'next' that steps forward _and_
also returns the resulting element in the iteration, rather than two magic-
named methods to perform the two tasks.  But "to start work on it" was
MOST definitely not the way to "get this into Python" -- _that_ would
most likely have been a total waste of effort.  Far better to get the idea
into the air and hope that somebody in the right place breathes it.


The __as_immutable__ and __as_temporarily_immutable__ methods
in Python's 2.3 sets.py's Set class are perhaps a start.  I think that the
next step is gaining a consensus about such methods being useful not
just to have sets (in their immutable versions) as members of other
sets, but also for (e.g.) lists as members of sets.  And for that purpose,
I think that no "start work on it" is any earthly use -- the pen is mightier
than the code.  We'll see...


Alex