tuples, index method, Python's design

[Paul Boddie]

On 10 Apr, 11:48, Antoon Pardon <apar... at forel.vub.ac.be> wrote:
> On 2007-04-10, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
>
> > There is a cost to every new language feature: it has to be implemented,
> > documented, maintained, and above all learned by the users. Good design
> > involves, in part, not adding to these burdens except where there is a
> > benefit at least equal to the cost.
>
> So what is the easiest to learn: "All sequences have an index method" or
> "Such and so sequences have an index method and others don't"

I think this observation leads to insights both at the end-user level
and at the implementer level. Tuples and lists are sequences; the
index method can be defined generically for all sequences; adding such
a method to the tuple type can be done with barely any changes to the
implementation taken from the list type. This leads to the observation
that a generic index method (defined as a function in the
implementation) could be made to work with both lists and tuples, and
that various other methods might also be defined similarly, although
things like append, extend and other mutating methods wouldn't be
appropriate for a tuple.

> Which of the above is the easiest to document?
>
> Now with implementation and maintaining. If you would start with a class
> of sequence which classes like tuple and list would inherit from, then
> there also would be a single function to be implemented and maintained.
> It would just be usable in more types.

There isn't a "big win" in this case: the intersection of useful
methods between mutable and immutable sequence types is rather small.
Nevertheless, providing a slightly deeper abstract class hierarchy
might be appropriate, and this is being considered for Python 3000.

[...]

> The same happened with the ternary operator. Every use case someone
> could come up with was rejected by rewriting the code without using
> a ternary operator. AFAICS the only reason the ternary operator
> finaly got introduced was because a python developer was bitten by an
> illusive bug, introduced by one of the idioms that was often used as a
> way to simulate a ternary operator.

The ternary operator, whilst providing new and occasionally useful
functionality, is rather "badly phrased" in my opinion: when used,
it's a bit like reading one natural language and suddenly having the
grammar of another in use for the rest of the sentence.

Paul