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.
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.