why not "'in' in 'in'"?

[John Roth]

"Grant Griffin" <not.this at seebelow.org> wrote in message
news:ae8dg70217g at drn.newsguy.com...
> Hi Gang,
>
> One of the things I like about Python is that it works as expected.
However, I
> sometimes accidently expect it to allow one to use "in" to determine
if one
> string is "in" another, e.g.:
>
> >>> 'in' in 'in'
>
> which yields a traceback:
>
>    Traceback (most recent call last):
>      File "<interactive input>", line 1, in ?
>    TypeError: 'in <string>' requires character as left operand

That doesn't seem very intuitive, does it? However, limiting
it as defined actually makes sense, because otherwise you
get ambiguities and boundary conditions.

> Evidently one is invited to use "count" or "find" instead:
>
> >>> 'in'.count('in') > 0
> 1
> >>> 'in'.find('in') >= 0
> 1
>
> I prefer "find" over "count" because it (presumably) punts after the
first
> occurrence.  However, neither one reads nearly as well as the
(illegal) "in"
> form.

Actually, the .count form is probably preferable, since it goes nicely
into an if statement - 0 is false and anything else is true. The .find
function is not so nice.

> So why is the "in" operator limited to single characters when used as
a
> membership operator?  This peculiar lack of generality seems a bit
(dare I say
> it?) "non-Pythonic".  (That said, "Pythonic" seems to be a bit like
> "enlightenment": those who claim to have mastered it wisely avoid
spelling out
> any concrete criteria by which others can judge their mastery <wink>.)

Actually, as far as I'm concerned, it's an anomaly, although I'm not
complaining.
When 'in' is used against any other kind of object, it takes whatever
type the
actual member of the sequence happens to be. Strings are a special case,
since there is no character type in Python.

> Perhaps its somehow due to the overloading of "in", which is used both
as a
> membership operator and as a separator gizmo inside "for" loops.
("It's a floor
> wax/No, it's a desert topping/No it's both!")  But is that any good
reason to
> exclude the handy, sensible, and downright intuitive use of "in" as a
substring
> detector?

No, that isn't the reason. 'in' is defined on sequences and mappings,
and has
the same semantics on either: does the particular member exist or not
within
the sequence or mapping. The usage in the 'for' statement is entirely
other.

Whether it's intuitive or not depends entirely on the speaker's
intuition. I,
for one, don't find it intuitive.

> Or maybe support for multiple characters would penalize the
performance of the
> single-character "in".

Python is not concerned with performance over clarity of expression. If
your suggestion would help clarity, it would be considered. However, it
does
not help clarity.

> Or maybe Tim just doesn't want to burden us with a third way to do it
<wink>.
>
> gotten-spoiled-to-Python's-habits-of-working-as-expected
>    -and-reading-as-pseudo-code-ly y'rs,
>
> =g2
>
>
________________________________________________________________________
_
>
> Grant R. Griffin
g2 at dspguru.com
> Publisher of dspGuru
http://www.dspguru.com
> Iowegian International Corporation
http://www.iowegian.com
>