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

[Thomas Wouters]

On Thu, Mar 13, 2003 at 12:07:09PM +0100, Alex Martelli wrote:
> 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.

I'm not sure whether that debunks or proves my point, as in my example I
throw away (part of) the design I already had.

> > 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.

Notice how I said it didn't require modification of the interpreter or of
builtin types; *that* kind of work can get rejected by Guido. A separate
module to accomplish a task is never wasted, as long as it's useful (and if
it's not useful, it shouldn't be added, right?) There are plenty of examples
for that: Cookie, email, bsddb3, even Zope's ExtensionClass to some extent.
And some, if not most, of the new modules that got written with the chief
intent of adding it to the stdlib (sets, for example, and email again) had
a lot of prior art to work with (or someone who was willing to dog Guido for
hours each day, like heapq<wink>)

> For example, when I first met Python in 1999 I posted a few ideas 
[ on iteration, which was rejected and later added as __iter__ ]

Not quite an analogous example. The iteration protocol requires interpreter
changes to be generally useful, as having to write 'for item in
iterator(object)' or 'for item in object.iterator()' almost negates the
purpose of having it. And I don't remember exactly how iterators came to be,
but I believe it had much to do with Tim Peters writing a simple
iterator/generator patch and showing Guido some example code, saying "Look
how Pythonic you think this looks." I'm sure Tim can shed some light on
that ;)

> 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...

Yes, PR is as important in selling an idea to Guido (or most people, in
fact) as code is. But *without* code, it becomes that much harder to sell,
even if it's just half-working, proof-of-concept, pseudo-code. And nothing
makes accepting more easy than having a working, community-accepted,
widely-used implementation ready and working. :-)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!