On 2016-05-30 20:08, Steven D'Aprano wrote:
How do you feel about an arrow operator?
T -> TypeVar() x -> Symbol() T -> type(bases, ns) Record -> namedtuple(fields)
name [, name, ...] -> callable(...)
where "callable" is some expression, e.g. a name, a dot lookup, etc.
# 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.
Using the arrow operator with arbitrary expressions on the right will be a SyntaxError:
x -> y + 1 my_name -> spam*f() my_name -> f() or g()
I reject that third example as it is unclear whether both f and g, or only f, get the name as first argument.
But this is allowed:
my_name -> f(g()) # like f('my_name', g())
So. . . what exactly will be allowed? Above you said the RHS would be "a name, a dot lookup, etc.". If you can't do it with at least dot lookups I don't see much point; you'd definitely want to be able to do this to create names from method calls. But it could get confusing to start splitting the expression syntax into portions that are allowed in this new "name-passing" syntax and portions that aren't.
The hard case
Assignment target(s) is not a plain name.
spam.eggs().attr -> Symbol()
I'm going to take the cowards way out and just say "we don't allow that".
That seems like the best way out. :-) It seems like the main purpose of this is as a shortcut to create an object with a simple, readable name. That goal isn't served by trying to assign some complicated expression.
Anyway, I still have a problem with solutions like this that separate the name from the expression in which it will be used. It seems crude to restrict this syntax to cases where the outermost callable takes the name as its first positional argument only. What if we want to pass the name by keyword or something? Or what if you want to do `f(g())` as in your example, but pass the name argument to g instead of f?
Because of that, I'm more inclined towards something that involves a placeholder in the actual expression (as someone else suggested elsewhere on this thread). Something like:
An expression could contain at most one "def name" token, and the result of the entire expression would be assigned to that name.
I acknowledge that this particular syntax isn't ideal, because the "def x" could be difficult to see in a complicated expression (although syntax highlighting would mitigate that). The construct could perhaps be introduced by a keyword to call out its unusual behavior:
assign Symbol(def x)
I'm just making up "assign" right now, not actually saying that's what should be used. Maybe some existing keyword could be repurposed. The upshot is that, to my eye, any solution that pulls the "name" argument out of the expression where it's used is to going to A) be confusing; and B) painfully restrict the use cases to those where the RHS is a very simple expression into which the name can be inserted at an easily-definable place. So I incline towards solutions that "tag" the name in-place in the expression, rather than pulling it out.