> On Sun, 26 Aug 2001, Eric S. Raymond wrote: > > You're right. But since a string can't be an element of a string, the > > case I'm really interested in would still work. > > It's arguable. A character can indeed be an element of a string, and > in Python characters are one-character strings. So this violates > > x in s <=> there exists i such that s[i] == x > > You could argue that strings should have special behaviour for "in" > to support the common case of finding a substring; then you would have > to argue on grounds of "practicality beats purity". > > I might support the argument on grounds of practicality beating purity, > but i'd have to think carefully about violating the above definition. > > I can see that "substring in string" would be very convenient, but then > > if char in '0123456789': ... > > would suddenly have a very different meaning -- it would succeed for > char = '12'. We *could* allow this for strings, but not for other sequences. For strings, type(s[0]) == type(s), and this avoids the ambiguity. The fact that currently ``noncharacter in string'' raises an exception makes it relatively painess to add semantics for it. But I'll have to think about why I ruled it out originall. I'll track down Eric here at LinuxWorld and discuss it with him, if we find time. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4