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

[Alex Martelli]

On Thursday 13 March 2003 01:20 pm, Thomas Wouters wrote:
   ...
> 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

Kludges to work around the lack of __as_immutable__ in built-in lists &c
would make near-useless any "separate module to accomplish the task"
of using (frozen copies of) lists as dict keys &c -- just as:

> 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

What makes you think that having to do somedict[freeze(somelist)]=xx and 
then check by "if tempfreeze(somelist) in somedict:" etc would be any
more "generally useful" than having to write "for item in iter(x):" ...?


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

There is ZERO chance of having a "community-accepted implementation"
for something that needs to be in the core to be useful -- and this holds for
a "freezing protocol" just as much as it holds for iterator.  When the needed
changes are obvious (and that is clearly so for "freezing", even more than
for iterators), developing a patch to implement the obvious is a 
just-as-obvious utter waste of time and energy that (if one IS keen to have
the change in the core) should instead be entirely deployed in "PR work".

Do you think that it makes ANY difference whether there's one or a million
patches to implement ternary operators -- will the existence of those patches
make ANY difference to the likelihood of Guido introducing a ternary op into
Python?!  *PAH*.  It's *STRICTLY* a matter of creating an upswell of popular
support -=- enough to get Guido to decide to hold a popular consultive vote
on the issue, AND enough to get (hypothetically) overwhelming support for
the change.  Ternary proponents managed the first but not the second --
we'll see what happens.  But NO MATTER how many patches they might
have written, all of them together would have been completely useless in
swinging a single popular vote, and thus a total waste of effort.

I think you're confusing the issue of changes that appear to present any
amount at all of technical difficulty, with that of changes which are entirely
obvious and bereft of any difficulty EXCEPT that of convincing Guido.

Working to develop patches is just as obviously "utterly useless" for the
latter kind, as it's "potentially useful" for the former kind.  And since a
"freezing protocol" is quite clearly in the latter category, thus do I believe
that your advice in the matter is totally wrong, misplaced, and misleading.


Alex