On Sun, 08 Jun 2014 18:56:47 +0300
Marko Rauhamaa <ma...@pacujo.net> wrote:
> Paul Sokolovsky <pmis...@gmail.com>:
> > Python already has that - like, len(x) calls x.__len__() if it's
> > defined
> In fact, what's the point of having the duality?
> len(x) <==> x.__len__()
> x < y <==> x.__lt__(y)
> str(x) <==> x.__str__()
> I suppose the principal reason is that people don't like UFCS. Plus
> some legacy from Python1 days.
I personally don't see it as "duality". There're few generic operators -
the fact that they are really generic (apply to wide different classes
of objects) is exactly the reason why the're defined in global
namespace, and not methods. And yep, I see things like "len" as
essentially an operator, even though its name consists of letters, and
it has function call syntax.
Then, there's just a way to overload these operators for user types,
that's it. You *can* use x.__len__() but that's not how Python intends
And like with any idea, one should not forget implementation side and
efficiency - these operators are really core and expected to be used in
performance-tight contexts, so they are implemented specially
(optimized). Extending that handling to any function would cost either
high memory usage, or high runtime cost.
> Lisp & co. rigorously follow its UFCS. I think it works great, but
> that is what people most ridicule Lisp for.
Exactly my thinking - there're bunch of languages which follow that
UFCS-like idea, likely most homoiconic (or -like) do. Or you can use
plain old C ;-). So, I don't see why people want to stuff this into
Python - there're lot of ready alternatives. And Python provides very
intuitive and obvious separation between generic functions and object
methods IMHO, so there's nothing to "fix".
> What do you think? Would you rather write/read:
> if size + len(data) >= limit:
"How else could it be?"
> or UFCS-ly:
> if size.__add__(data.__len__()).__le__(limit):