[Python-ideas] Add .= as a method return value assignment operator

[Jasper Rebane]

I had the number 4 in mind
Though I think your idea is way better, as it's more flexible and less
confusing

On Fri, Sep 28, 2018, 10:33 Brice Parent <contact at brice.xyz> wrote:

>
> Le 27/09/2018 à 12:48, Ken Hilton a écrit :
>
> Hi Jasper,
> This seems like a great idea! It looks so much cleaner, too.
>
> Would there be a dunder method handling this? Or since it's explicitly
> just a syntax for "obj = obj.method()" is that not necessary?
> My only qualm is that this might get PHP users confused; that's really not
> an issue, though, since Python is not PHP.
>
> Anyway, I fully support this idea.
>
> What would the following evaluate to?
> a .= b + c(d)
>
> 1: a = a.b + a.c(a.d)  # everything is prepended an "a."
> it means we dn't have access to any external elements, making the
> functionality only useful in a few cases
>
> 2: a = a.b + a.c(d)  # every first level element (if that means something)
> is prepended an "a."
> We still lose some of the ability to access anything outside of `a`, but a
> bit less than in #1. The effort to understand the line as grown a bit,
> though.
>
> 3: a = a.(b + c(d))  # everything is evaluated, and an "a." is prepended
> to that result
> (the same way `a *= 2 + 3` is equivalent to `a *= 5`)
> I believe in most cases, this wouldn't mean anything to evaluate `b +
> c(d)` on their own, and expect a return that can be used as an attribute of
> `a`.
>
> 4: a = a.b + c(d)  # "a." is prepended to the first element after the `=`
> It is probably quite easy to read and understand, but it removes the
> transitivity of the operators we have on the right, and is a bit limiting.
>
> 5: SyntaxError: Can only use the [whatever the name] augmented operator
> with a single expression
> Why not, it's a bit limiting, but is clear enough to me.
>
> Maybe, a simpler thing to do for this problem would be to make something
> like this:
> a = .b(5) + c(.d) + 3
> being the equivalent of
> a = a.b(5) + c(a.d) + 3
>
> I don't see any ambiguity anymore, it shortens the code a lot, and I guess
> it wouldn't be hard for the compiler to recompose the line as a first
> parsing step, and create the same AST with both syntaxes.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180928/5ceaf16c/attachment.html>