> > > I guess the tests should be faster, yes, but I would still want > > > _iterables_ for ascii_* and digits. > > > > Why? It's not like you're going to save much space by not creating a > > string of 52 bytes. > > Strings are iterables. What I'm saying is that I don't necessarily need > them to be strings, if having iterables that aren't strings (perhaps a > string subclass redefining just __contains__) would help with: An example given earlier: string.letters + string.digits + "_" indicates that we want them to be concrete strings. > > > One issue with allowing "if char in string.letters:" is that these > > > days this will not raise if the alleged 'char' is more than one > > > character -- it will give True for (e.g.) 'ab', False for (e.g.) > > > 'foobar', since it tests _substrings_. > > > > Right. > > > > > So, maybe, str.letters and friends should be iterables which also > > > implement a __contains__ method that raises some error with helpful > > > information about using .iswhatever() instead -- that's assuming we > > > want people NOT to test with "if char in str.letters:". If we DO > > > want people to test that way, then I think str.letters should > > > _still_ have __contains__, but specifically one to optimize speed in > > > this case (if supported it should be just as fast as the > > > .is... method -- which as Skip reminds us may in turn need > > > optimization...). > > > > Hm. The iterable idea seems overblown for something as simple as > > this. > > Is presenting this as "a subtype of str that overrides __contains__ > appropriately" more acceptable? No, I think it's being too clever. --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