Re: tuples, index method, Python's design

On 2007-04-13, Steve Holden <steve@xxxxxxxxxxxxx> wrote:
Antoon Pardon wrote:
On 2007-04-13, Steve Holden <steve@xxxxxxxxxxxxx> wrote:
Antoon Pardon wrote:
On 2007-04-12, Carsten Haese <carsten@xxxxxxxxxxx> wrote:
On Thu, 2007-04-12 at 14:10 +0000, Antoon Pardon wrote:
People are always defending duck-typing in this news group and now python
has chosen to choose the option that makes duck-typing more difficult.
Au contraire! The "inconsistent" behavior of "in" is precisely what
duck-typing is all about: Making the operator behave in a way that makes
sense in its context.
No it isn't. Ducktyping is about similar objects using a similar
interface to invoke similar behaviour and getting similar result.

So that if you write a function you don't concern yourself with
the type of the arguments but depend on the similar behaviour.

Please note that "similar" does not mean "exact".

That is because I don't want to get down in an argument about
whether tp[:3] and ls[:3] is similar behaviour or exact the
same behaviour when tp is a tuple and ls is a list.

The behavior of str.__contains__ and list.__contains__ is similar.

That would depend on how much you find things may differ and
still call them similar. IMO they are not similar enough
since "12" in "123" doesn't behave like [1,2] in [1,2,3]

And it never will, because of the property of strings I mentioned
previously. Unless you want to introduce a character type into Python
there is no way that you are ever going to be be satisfied.

The properties of strings didn't force the developers to make those
two behave differently. They could have made the choice that "12"
in "123" returned False and could have introduced a method that would
return True or False depending on whether the argument was a substring
or not. The same method could then eventually be used in other sequences
to test whether the argument was a subsequence or not. Either by
the python-developers themselves if they ever thought that usefull
or by any programmer who could add this functionality to a subclass.

Yes the properties of strings allowed for the solution the python
developers have chosen, a solution not extendable to other
sequence types. So yes [1,2] in [1,2,3] will never behave like "12" in
"123" currently does and the properties of strings allowed it to evolve this way
but in the end it was a design choice that could have been made differently
and could have been made in a way to allow more duck typing and more
access to polymorphism.

And consider that each small inconsistency in itself
may be not important enough to remove. But if you
have enough of them remembering all these special
cases can become tedious.

But not as tedious as this eternal discussion of already-decided issues.

A number of those "decided" issue have been changed. Besides
nobody is forcing you to participate. If you think these
kind of issues is too tedious for your taste, feel free
to no longer participate.

Strings have some properties that are different and some
properties that are similar with other sequences. My argument
is that if you want to facilitate duck typing and natural access to
polymorphism in peoples functions that work with sequences in general
you'd better take care that the sequence api of strings resembles
the sequence api of other sequences as good as possible.

This is just a bald restatement of the same argument you feel makes it
desirable to add an index() method to tuples.

No it is not a bald statement. If tuple would have methods like index
and count, more functions could be written that are indifferent to
the argument being a tuple or a list or at least it would make
writing such a function easier, so it would allow for more
duck typing and give more access to polymorphism.

You may think this kind of duck typing and polymorphism insignificant
but that doesn't change the truth about the above statement.

If taken to its logical
(and ridiculous) extreme there should only be one sequence type in Python.

No it doesn't. There is a big difference between having sequences with
different properties because there is a need for those different
properties and making things more different than needed and using
the need for different properties to introduce differences that are
unnecessary.

You on the other hand seem to argue that since strings have
properties where they differ from other sequences it no longer
is so important that the sequence api of strings resembles those
of other sequences.

Well, of course. Programming languages are for human users, and they
should do what human users find most natural. Since humans can disagree
the developers (amongst who I do not count myself, although I *am*
concerned about the development of Python) have to try and go by
consensus, which by and large they do reasonably successfully.

But the defence of not having tuple.index has never been about
what was natural to the user or not, but has always been about what
tuples were supposedly intended for.

So what I suppose I *am* saying is that your opinions would seem to
differ from the consensus. While you are not in a minority of one you
are in a minority, and it would be nice if we could proceed without
having to continually revisit each small design decision on a continuous
basis.

I am not so sure I'm in a minority. This kind of thing is not decided by
consensus at least not among the python users. It is the sole decision of
the BDFL. Besides, this is usenet, all kind of things get revisted here on
a continuous basis. Why should design decisions be an exception?

--
Antoon Pardon
.

Relevant Pages

  • Re: Bug in string.find; was: Re: Proposed PEP: New style indexing,wasRe: Bug in slice type
    ... The numbers represent points separating unit intervals and representing the ... minuses; Python rounds down. ... strings and sequences are finite and have a right end also. ...
    (comp.lang.python)
  • Re: tuples, index method, Pythons design
    ... Strings are special in that scan only be a string of length 1. ... That's because strings are different from other sequences. ... This was discussed on python-dev when Python adopted the enhanced semantics for "in" on strings - formerly only tests for single characters were allowed - but wasn't thought significant enough to deny what was felt to be a "natural" usage for strings only. ...
    (comp.lang.python)
  • Re: tuples, index method, Pythons design
    ... Strings are special in that scan only be a string of length 1. ... That's because strings are different from other sequences. ... This was discussed on python-dev when Python adopted the enhanced semantics for "in" on strings - formerly only tests for single characters were allowed - but wasn't thought significant enough to deny what was felt to be a "natural" usage for strings only. ...
    (comp.lang.python)
  • Re: Complex Specified Information - Pitman Formula
    ... you go out to analyze any other sequences. ... other reference you give. ... is it possible for a set of reference strings to miss a non- ... sequences is likely to be non-random in origin. ...
    (talk.origins)
  • Re: Complex Specified Information - Pitman Formula
    ... you go out to analyze any other sequences. ... other reference you give. ... is it possible for a set of reference strings to miss a non- ... sequences is likely to be non-random in origin. ...
    (talk.origins)