On Friday 07 November 2003 23:49, Guido van Rossum wrote: > > 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: > > 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? Alex
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