On Wed, Sep 30, 2020 at 1:43 PM David Mertz <me...@gnosis.cx> wrote:
> Fluent programming is uncommon in Python, and hence few methods return a
> call of the same or similar type.
>
I think that if you include built-in operators as (shorthand for) method
calls, and you count the number of occurrences in typical Python programs
rather than the number of distinct species, it's common.
I don't know if I necessarily support this idea, but it makes sense as a
generalization of the existing augmented-assignment syntax to operations
that are conceptually similar, but are written with method-call syntax
because Python lacks operators for them.
The fact that methods are inconsistent about mutating in place versus
returning a new object, and it's sometimes hard to guess from the name
which will happen, is unfortunate but I don't think this proposal makes the
problem any worse.
Here are a few cases where the syntax would be useful for values other than
strings:
named_tuple .= _replace(...)
pil_image .= crop(...)
numpy_array .= transpose()
node .= get_{parent,left_child,right_child}()
mutable_thing_from_caller .= copy()
What I dislike about this syntax is that it makes no grammatical sense
since . isn't a binary operator and the thing on the right isn't an
expression.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/U52S44ZO7SQCWWUJIHQE7YKQWBLO4FYE/
Code of Conduct: http://python.org/psf/codeofconduct/
