On Sun, 8 Jun 2014 01:26:04 -0700 (PDT)
jongiddy <jongi...@gmail.com> wrote:
> On Sunday, 8 June 2014 02:27:42 UTC+1, Gregory Ewing wrote:
> > Also it doesn't sit well with Python's "one obvious
> > way to do it" guideline, because it means there are
> > *two* equally obvious ways to call a function.
> This provides a way to do something new (add class-optimized
> implementations for existing general-purpose functions).
Python already has that - like, len(x) calls x.__len__() if it's
defined (for objects where it makes sense for it to be defined). Many
builtin functions have such behavior. For your custom functions, you
can add similar conventions and functionality very easily (if you'll
want to apply it to "not your" types, you'll need to subclass them,
Getting x.foo() to call foo(x) is what's bigger problem, which has
serious performance and scoping confusion implications, as discussed in
> It also adds
> significant readability improvements by putting function-call chains
> in order.
Not sure what exactly you mean, but the order is usually pretty obvious
- Python follows mathematical notation for function calls, and OO
standard notation for method calls, one known from primary school,
another from secondary (hopefully). They can be reordered with
parentheses, which is also well-known basic math technique.