Ka-Ping Yee wrote: > >... > > Hmm. And what of, say, abs(-3)? Should that be -3.abs()? The former is more in-line with traditional mathematical notation. I think that counts for something. And anyhow, abs is not fully polymorphic so it is a little bit of a different case. > Would you also argue for [1, 2, 3].repr() and "abc".hash()? Yes. But hashing and repring are done much less often than taking the length. So I wouldn't worry about them...in this round anyhow. Plus repr has a first-class syntax so the function is kind of redundant already! > Where do you draw the line? If a function takes a single argument that is a Python object and immediately dispatches to a magic method, and it is "important" enough to be a builtin, then it should probably just be a method. What is the point of hiding what is really going on -- a method call! > Maybe my habits are too ingrained > at this point, but i kind of like the boundary between __methods__ > and ordinary methods... it would somehow bug me to have all these > methods like abs, len, hash crowding in on my ordinary-method > namespace. I can appreciate that your tastes are different from mine...in fact I said something similar to David when he first suggested it to me but on reflection it seemed such a subtle thing when compared against the weirdness of the definition of len: def len(obj): return obj.__length__() It does a little bit more but not much! If you put that in a module you wrote you would consider it a little bit bizarre, useless and confusing. Plus it is another indirection which saps a tiny bit of performance for nothing. -- 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