> 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. > 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. --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