Paul Boddie wrote: > On 10 Apr, 11:48, Antoon Pardon <[EMAIL PROTECTED]> wrote: >> On 2007-04-10, Duncan Booth <[EMAIL PROTECTED]> 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. > A generic definition of index would be tricky, though, if you wanted to include strings as sequences. In that case you aren't testing for the presence of a single element but a sub-sequence - I think this change was introduced in 2.4 to allow checks like
"men" in "three good men" to succeed where formerly only single characters could be checked for. One might perversely allow extension to lists and tuples to allow [3, 4] in [1, 2, 3, 4, 5, 6] to succeed, but that's forcing the use case beyond normal limits. The point I am trying to make is that circumstances alter cases, and that we can't always rely on our intuition to determine how specific methods work, let alone whether they are available. I hear the screams of "just add the index() method to tuples and have done with it" and, to an extent, can sympathize with them. But that way lies creeping featurism and the next thing you know we'll have a ternary operator in the language - oh wait, we do now! >> 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. > Indeed the syntax is deliberately "crippled" - Guido's reasoning being, I believe, that if it were too easy and natural to use then people would use it inappropriately and too frequently. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Recent Ramblings http://holdenweb.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
