Hello, 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, as expected). Getting x.foo() to call foo(x) is what's bigger problem, which has serious performance and scoping confusion implications, as discussed in other mails. > 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. -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list