"in" operator for strings

[Steve Holden]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:95eb4r0csk at news1.newsguy.com...
> "Cliff Crawford" <cjc26 at nospam.cornell.edu> wrote in message
> news:QPee6.1195$o91.132115 at typhoon.nyroc.rr.com...
> > * Alex Martelli <aleaxit at yahoo.com> menulis:
>     [snip]
> > | of this 'obvious' generalization, specialcasing string would
> > | surely not be warranted).
> >
> > Strings seem to be special-cased already; for example, you don't have to
> > type
> >
> > >>> print ''.join(['H','e','l','l','o',',',' ','w','o','r','l','d','!'])
> >
> > if you don't want to <wink>.
>
The most anomalous thing about strings from my point of view is the lack of
a character dataype.  So

>>> lst = [1, 2, 3]
>>> type(lst)
<type 'list'>
>>> type(lst[1])
<type 'int'>
>>> strng = "123"
>>> type(strng)
<type 'string'>
>>> type(strng[1])
<type 'string'>

I wouldn't seriously argue that we _need_ a character type, but it's
certainly anomalous that an element of a sequence is itself a sequence.
Just the same, this kind of pragmatism is what keeps Python in the forefront
of popularity (in so far as it is).

[ ... ]

> > This is probably the best solution, since I'm sure no one will go for
> > yet another change to the language <0.3wink>.
>
> The language keeps being changed (and there are grumblings
> whenever that happens, of course).  A change to make strings
> not sequences would probably be too pervasive to consider,
> breaking zillions of lines of working code.  A change to
> break the uniformity in the behavior of sequences of various
> types is unfortunately more conceivable, but it would be an
> very very bad idea if it ever happened.
>
Python 2.0 came long enough after 1.5.2, and contained enough improvements,
that most users would take whatever pain there was in converting as the
price of gaining access to the new features ... all except "print >>," that
is, which was and remains an abomination on the syntax of the language
worthy of Bill Gates at his worst (he did write code, and I suspect that
much of it was awful). Execrescence. Mother of all warts. Martelli shall not
be forgotten!

But now here we are, less than six months after a major release, looking at
tweaks and fiddles and optimizations. It strikes me that the Python
community is in danger of falling victim to the "see how much more we can
stuff in without breaking backwards compatibility" syndrome.  Just because a
proposed change doesn't break existing code doesn't necessarily make it a
good thing. Subtle changes to the semantics of the language invalidate
teaching materials, for example.

The situation seemd to me to be better and more rational when we expected
Python 3K to be a major break from current traditions. At least this gave
the twiddlers and the tweakers some hope, without putting the existing
language at risk. There are undoubtledy arguments for many of the 2.1
changes, but I findsome of them unconvincing. Why not keep Python as it is
now, and prodce 3K about 998 years early?

There's a lot to be said for stability.

wishing-i-had-a-bit-more-myself-ly y'rs  - steve