> David Ascher wrote: > >Again, I wasn't considering getting rid of old builtins. We're going to > >be adding new methods to all of the types anyway (since they'll derive > >from object), so I was just suggesting that len or length be an alias > >for __len__. James Althoff: > (While admittedly being an OO zealot ;-) I too would be pleased to see a > len/length method. And I really enjoy using the new string methods. > Thanks for adding them! :-) While it will admittedly take a while, the intention of string methods was to eventually phase out the string module. So TOOWTDI is only violated during the transition. If we decide to add a len() method, we'll also have to decide to (eventually) get rid of len(), or we'd violate TOOWTDI *permanently*. Personally, I don't think that the "problem" this change is addressing is worth asking everybody to change their code -- so we'd have live with len(x) and x.len() as viable ways to ask for x's length *forever*, violating TOOWTDI permanently. I don't like that. (You may disagree, but at least I have thought about it and I can explain my motivation. :-) --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