> Do you really think this proliferation of issomething() > methods is a good idea ? To tell you the truth, I'm not sure. Maybe we should stick to supplying replacements for the character set variables in the string module; this would mean adding replacements for hexdigits, octdigits, punctuation, and printable. Also, the string module defines ascii_lowercase, ascii_uppercase, and ascii_letters; maybe an isascii() replacement would be the best approach there. (I've never seen those used, but they exist, so if we want to slowly start discouraging people from using the string module, I feel we're obliged to privide an alternative. > The same can be had using re.metch() with *much* more flexibility > since you're not stuck with an "intuitive" definition relying > on the intuition of some non-standard body. I'm not sure what you're trying to say. The re module's definition of "word" characters (which includes '_') is definitely non-standard. How do you spell "letter according to locale" in a regexp? > FWIW, I've never used a single one of these single > character based classification APIs. The only non-trivial > issomething() method I can think of is .istitle() because > of it's complicated definition. All others can easily > be had with re.match(). > > I'm -0 on adding more of these .issomething() APIs > to strings and Unicode. Noted. But what do you propose we should do in 3.0 about the character set variables in the string module? --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