tuples, index method, Python's design

[Chris Mellon]

On 11 Apr 2007 08:37:39 -0700, Paul Boddie <paul at boddie.org.uk> wrote:
> On 11 Apr, 16:14, "Chris Mellon" <arka... at gmail.com> wrote:
> >
> > If you want a language that just adds whatever methods anyone thinks
> > of, along with whatever aliases for it any can think of, to every data
> > type, you know where to find Ruby.
>
> Nobody is asking for Ruby, as far as I can see. I even submitted a
> quick patch to provide tuple.index (a method that has already been
> thought of), given the triviality of the solution, but you won't find
> me asking for a bundle of different convenience methods with all their
> aliases on every object, regardless of whether you can monkey-patch
> them after the fact or not. For example:
>

Note that the mail I responded to was using being drunk, not knowing
any better, and having fun as use cases for the method. That sounds
like Ruby-style method proliferation to me ;)


> Note that, in that document, index and count are methods of
> MutableSequence. Quite why this should be from a conceptual
> perspective is baffling, but don't underestimate the legacy influence
> in such matters.
>

Well, I'm not Guido obviously, but here's why I don't find it baffling.

There are 2 main reasons why you'd use an immutable sequence for something:
1) You want to make sure it's not modified by a callee. This is
unPythonic and mostly unnecessary. Pass them a copy if you're that
paranoid.

2) Because you are representing a known, structured data type. This
can be either unordered, in which case index() is meaningless (as in
frozenset), or it can be ordered, in which case the order is an
implicit part of the structure. In such a case, index() is also
meaningless, and should never be necessary.

The primary use case for index on tuple is because people use them as
immutable lists. That's fine as far as it goes, but I want to know
what the justification is for using an immutable list, and if you have
one why you need to use index() on it. There's only 2 use cases I've
heard so far for that: certain types of binary parsing, which I don't
think is common enough to justify modification to the language core,
and third party libs returning silly things, which I *certainly* don't
think justifies changes to the language core.

I'm pretty against tuples growing index() ever. I think that if there
is a real need (and just because I haven't seen one doesn't mean it's
not there) for an immutable list, the introduction of fozenlist() to
the collections module (or something) would be a better solution. On
the other hand, if tuples grew list methods and we got a new immutable
sequence that had order, unpacking, and *named fields* along the lines
of Pascal records I'd be happy with that too.