[Python-ideas] Quick idea: defining variables from functions that take the variable name

[Brendan Barnwell]

On 2016-06-01 11:30, Steven D'Aprano wrote:
> On Tue, May 31, 2016 at 11:13:30AM -0700, Brendan Barnwell wrote:
>
>>> > ># okay
>>> > >name -> sympy.Symbol()
>> >
>> >	I don't like this that much, because it looks odd to have the
>> >expression on the right without the argument.  The syntax doesn't make
>> >it at all clear how the T gets used on the RHS.
> *shrug*
>
> You have to learn it, just like you have to learn decorator syntax. It's
> literally a*one sentence explanation*:
>
> "The name on the left hand side is passed to the function on the right
> hand side, as a string, as the first positional argument."

	It is simple, but if the functionality is that limited, I don't think 
I'm in favor of adding it.  Your proposal would handle essentially 
nothing but the two or three mentioned usecases, and would not be 
generalizable to others, because of the restrictions on the kinds of 
expressions allowed on the RHS.  That's a fair amount of magic to 
accomplish relatively little.

	Decorators are different, because the decorator applies to the *result* 
of the thing it wraps.  That is, the normal function definition results 
in a function object, and the decorator acts on the resulting object. 
Since the decorator is only getting one thing, there isn't much choice 
about "where" that thing should go in the call expression.  But in the 
name-passing case, the name is meant to actually be used within the 
expression on the right, so it has to get inserted before that 
expression is evaluated, and then you have questions about where to 
insert it.

	Your proposal gets around this by restricting the form of the RHS so 
that there are fewer possible insertion points.  But that's also not 
parallel to decorators, because decorators apply to functions (and 
classes), and there's no way to define more than one function (or class) 
"at the same time", so stipulating that a decorator can apply only to a 
single definition doesn't lose anything.  In other words, there's 
nothing you can do in a normal function definition that you can't do in 
a decorated function definition.  But with this new syntax, there is a 
great deal you could do in a normal expression that you can't do in a 
name-passing expression.

	I agree that your proposal is more simple and straightforward than some 
of the others that have been proposed.  But for my money, it's not worth 
adding new syntax just to handle simple cases like `x = Symbol('x')`, 
and as I see it, that's essentially all this new syntax would handle.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."
    --author unknown