Guido van Rossum wrote: >>How about a strtools module? I was thinking that constants like >>ascii_letters could go there along with an implementation of join() that >>took arguments in an obvious way (or at least the way everyone seems to >>request it). Barry's string replacement function could also go there >>(the one using $; wasn't it agreed that interpolation was the wrong term >>to use or something?). >> >>This would prevent polluting the str type too much plus remove any >>hindrance that there necessarily be a mirror value for Unicode since the >>docs can explicitly state it only works for str in those cases. > > > Do we have an indication that the str type is getting polluted too > much? As of right now? Not really, but this might lead down that road (probably being overly cautious on this). I do agree with Fred in that I would be just as happy to have them in a module. Might be a bias I have developed about keeping *everything* in a class/type or instance (I blame Java =). I really don't mind if they get added to the type; moving them to another module just seemed like a cleaner solution to me. I am basically: +0 for making the constants a class variable (really more like +.5, but rounding screws that up) -1 for leaving the string module (I agree with Francois' argument about the name, plus we have said it is going to be deprecated for so long I would like to see it through) +1 for moving them to another module that can have generic string-helping functions -Brett
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