On 14 Jul 2019, at 22:46, Andrew Barnert <abarnert@yahoo.com> wrote:
First, the function only gets the names, not live expressions that it can eval late, or in a modified environment, etc., so it only handles this case, not cases like df[year>1990].
I don't understand how it's not the full expression. It's the expression as a string but it's still the full code.
But this doesn’t in any way help with late eval. The caller has already evaluated the expression to pass the value of the keyword argument. The fact that you could ignore that value and re-do the eval doesn’t help if the eval would raise a NameError like the year>1990 case (or if it would do something expensive or dangerous).
Ah. Now I'm with you. Yes this is different but it also seems strange that we wouldn't just use a lambda or a function for that. That's exactly why they exist.
Finally, while this is a less serious problem than the last two, the same string isn’t guaranteed to compile to the same AST in two different contexts. Consider how your proposal would play with libraries that insert token or AST processors.
Hmm, well I've never seen one of those outside toy programs but I'll concede the point.
But in the case of plot(=lambda x:x*2, =lambda x:x**2), you’re saying that the callee has a variable named lambda x:x*2, which is not true. What the callee actually has is two unnamed positional arguments, each of which comes with an extra string argument buried as its name.
I disagree. The callee has a thing called that, it just isn't a variable but a local expression. And in any kwargs have never meant that the caller has a variable by the name of the callee argument so why would it here?
(The fact that they’re positional, but passed as if they were keyword, accepted as if they were keyword, and then pulled out by iterating **kw in order is also confusing.)
What is positional? Everything here is keyword. We must be talking past each other. My proposal is just a different short syntax for keyword arguments at the call site.
This could work for any expression:
foo(=lamda x: x*2) -> foo(**{'lamda x: x*2': lamda x: x*2})
Is this actually legal? The docs just say the contents of the ** mapping are treated as additional keyword arguments. CPython happens to check that they are strings but not check that those strings are valid keywords, but I don’t think the language definition actually says this is the intended behavior, it’s just an accident of the CPython implementation. So this might require at least defining that implementation behavior as the only correct one, and changing the docs to explain it.
You are correct. I have checked that this is the behavior of CPython, pypy, micropythob, iron python, and jython so shouldn't be a big burden.
This might actually be a good change even on its own. The fact that the docs aren’t clear on what can go in a **kw is probably not a strength of the language definition but a flaw. If every implementation does the exact same thing (especially if it’s been that way unchanged in every implementation from 2.3 to 3.8), why not document that as the rule?
Agreed! If you don't follow this you are de facto a broken python implementation even if the spec allows it.
This feature is easy to implement and has broad applications.
How is this implemented? Doesn’t the compiler have the same problem generating a string for the keyword out of an AST that the user code would have in the OP’s proposal?
Sure. The lack of round tripping in the standard library AST is a problem but in this case a simple AST dump is most likely fine even if it loses the users specific formatting.
It’s not just about a lack of round tripping in the standard library AST, it’s about a lack of round tripping in the implementation of the CPython, PyPy, etc. compilers. If the compilers don’t have access to that information internally, they can’t put it in the output.
And I think it would be pretty confusing if spam(=eggs+cheese) gave you an argument named “eggs + cheese” instead of “eggs+cheese”. And it would be annoying if you were using it to define labels on a displayed graph—you keep trying to tweak the code to change how the label is written and it doesn’t do what you tell it to do.
Agreed. But there must be a way to explicitly specify the label anyway so I don't think this is a deal breaker. / Anders