Guido van Rossum wrote: > >... > > AFAICT, the len() method proposal is just an attempt to be more OO, > and to avoid being made fun of by a bunch of Perlers. I don't care > about #1, and it's naive to think that solving one issue will avoid > #2. OO is merely accidental. The real goal is to be more consistent. Python is a language that uses methods for polymorphism so consistency pushes towards methods. If Python were Scheme and had an OO appendage in the middle of its standard library I'd dislike that too. The only reason Perlers come into the picture is because they are pointing out that we claim to be consistent but in this case are not. And the only reason any of us care about consistency is because inconsistency has a cost in education and memorization...and according to Greg Wilson he's seen it first-hand in this case. (I personally had more experience with confusion over string functions instead of string methods) > Any change like this has a *huge* cost to the community (just reread > the division thread). Division is a special case. There is a big difference between re-purposing existing syntax and adding new methods to existing objects. If one is clearly the "new, better" way and the other is historical, then the books document the new way and most users eventually forget that the old way even exists. e.g. string exceptions, string.functions, UserDict (after type-class), regex, etc. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook
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