On Tue, May 25, 2021 at 8:11 AM Chris Angelico <ros...@gmail.com> wrote:
> On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano <st...@pearwood.info>
> wrote:
> > Here's a counter-proposal: we have a special symbol which is transformed
> > at compile-time to the left hand assignment target as a string. Let's
> > say we make that special expression `@@` or the googly-eyes symbol.
>
> This is sounding promising. I'm liking this.
>
> ...
>
> > Chained assignments transform to a tuple of target names:
> >
> > spam = eggs = cheese = func(arg, @@)
> > # spam = eggs = cheese = func(arg, ('spam', 'eggs', 'cheese'))
>
> Hmm. Everything else gives you a single string, this one doesn't. I'd
> actually be inclined to switch around this one and the next one...
>
> > Sequence unpacking assignment gets transformed as a single
> > comma-seperated string:
> >
> > spam.eggs, foo, *bar = func(arg, @@)
> > # spam.eggs, foo, *bar = func(arg, ('spam.eggs,foo,*bar'))
>
> ... so that assigning the same thing to multiple names gives you a
> space-separated string (or equals-separated, "spam=eggs=cheese"), but
> unpacking gives you a tuple of targets, since it then nicely parallels
> the result it's expecting from the function. That would mean that:
>
> # This assigns a single string to them all eg "spam eggs cheese"
> spam = eggs = cheese = @@
> # This assigns a string to each one:
> spam, eggs, cheese = @@
> # and is equivalent to:
> spam = @@; eggs = @@; cheese = @@
>
> ...
>
> No wrong answers. (Well, unless you say "tomato". That is a very wrong
> answer to a yes/no question.)
>
> I'm liking this. It might mean that class syntax and decorator abuse
> become less necessary as ways to get around name duplication.
>
> ChrisA
(In the spirit of no wrong answers!)
One of the motivating examples from the OP's post was symbolic math. As
such I think this looks pretty nice (side note: in sympy the sympy.Symbol
factory name is symbols, not symbol):
# x = symbols("x")
@symbols x
For a single symbol, it would be this using Steven D's googly-eyes counter
proposal, which also looks good to me:
# x = symbols("x")
x = symbols(@@)
I think Steven makes a good case that the googly-eyes brings with it the
best part of the OP's proposal, and avoids inconsistent, probably confusing
decorator behavior (compared to function decorators).
Continuing on with Steven's counter proposal and the motivating example of
symbolic math, for multiple symbols it would be this:
# x, y, z = symbols( 'x,y,z' )
x, y, z = symbols(@@)
However, even though it works for the symbols example, this meaning looks
odd to me:
# x, y, z = symbols( 'x,y,z' )
...it seems like this should in fact be *three separate assignment
operations*, not a single assignment operation. So, instead:
x, y, z = symbols(@@)
# three assignments, not one (and this is Chris A's suggestion!):
# x = symbols( 'x' ); y = symbols( 'y' ); z = symbols( 'z' )
This version also works for the symbols example, though it calls the
factory function 3 times rather than 1. Is that an important downside?
I am on the fence for the better meaning of this:
x = y = z = symbols(@@)
# x = y = z = symbols( ('x', 'y', 'z') ) # Steven's -- produces
(Symbol('x'), Symbol('y'), Symbol('z')) )
# x = y = z = symbols( 'x y z' ) # Chris' version 1 -- produces
(Symbol('x'), Symbol('y'), Symbol('z'))
# x = y = z = symbols( 'x=y=z' ) # Chris' version 2 -- produces
Symbol('x=y=z')
As noted above, for all three versions if a user tried this it may appear
to work at first (no immediate errors) but in actuality, x, y, and z would
almost certainly not contain what the user wants. This seems potentially
frustrating?
I note that the symbols example is not the be-all end-all example, but
going through it was instructive for me on what the differences of Steven's
and Chris' suggestions are. And maybe other examples would behave
similarly? Unsure.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
_______________________________________________
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/64PW7WNONEWRO2LAEEYE2GLFUFIKFNQZ/
Code of Conduct: http://python.org/psf/codeofconduct/
