On 11 Apr 2007 08:37:39 -0700, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 11 Apr, 16:14, "Chris Mellon" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
