David, I saw now that I missed the biggest problem with your proposal: yet again you deliberately throw away errors. I'm talking about making Python code _less_ error prone, while you seem to want to make it _more_. Anyway, I'll modify your reach() to not have the if in it that has this error hiding property, it also simplifies it a lot. It should look like this: def reach(name): return inspect.stack()[-2][0].f_locals[name]

1. Huge performance penalty

Huh? Have you actually benchmarked this is some way?! A couple lookups into the namespace are really not pricey operations. The cost is definitely more than zero, but for any function that does anything even slightly costly, the lookups would be barely in the noise.

I'm talking about using this for all or most function calls that aren't positional only. So no, you can absolutely not assume I only use it to call expensive functions. And yea, I did benchmark it, and since you didn't define what you would think is acceptable for a benchmark you've left the door open for me to define it. This is the result of a benchmark for 10k calls (full source at the very end of this email): CPython 3.6 time with use: 0:00:02.587355 time with standard kwargs: 0:00:00.003079 time with positional args: 0:00:00.003023 pypy 6.0 time with use: 0:00:01.177555 time with standard kwargs: 0:00:00.002565 time with positional args: 0:00:00.001953 So for CPython 3.6 it's 2.587355/0.003079 = 840x times slower and pypy: 1.177555/0.002565 = 460x slower I'm quite frankly a bit amazed pypy is so good. I was under the impression it would be much worse there. They've clearly improved the speed of the stack inspection since I last checked.

2. Rather verbose, so somewhat fails on the stated goal of improving readability

The "verbose" idea I propose is 3-4 characters more, per function call, than your `fun(a, b, *, this, that)` proposal. It will actually be shorter than your newer `fun(a, b, =this, =that)` proposal once you use 4 or more keyword arguments.

True enough.

3. Tooling* falls down very hard on this

It's true that tooling doesn't currently support my hypothetical function. It also does not support your hypothetical syntax.

If it was included in Python it would of course be added super fast, while the use() function would not. This argument is just bogus.

It would be *somewhat easier* to add special support for a function with a special name like `use()` than for new syntax. But obviously that varies by which tool and what purpose it is accomplishing.

Easier how? Technically? Maybe. Politically? Absolutely not. If it's in Python then all tools _must_ follow. This solved the political problem of getting tool support and that is the only hard one. The technical problem is a rounding error in this situation.

Of course, PyCharm and MyPy and PyLint aren't going to bother special casing a `use()` function unless or until it is widely used and/or part of the builtins or standard library. I don't actually advocate for such inclusion, but I wouldn't be stridently against that since it's just another function name, nothing really special.

Ah, yea, I see here you're granting my point above. Good to see we can agree on this at least. / Anders Benchmark code: ----------------------- import inspect from datetime import datetime def reach(name): return inspect.stack()[-2][0].f_locals[name] def use(names): kws = {} for name in names.split(): kws[name] = reach(name) return kws def function(a=11, b=22, c=33, d=44): pass def foo(): a, b, c = 1, 2, 3 function(a=77, **use('b')) c = 10000 start = datetime.now() for _ in range(c): foo() print('time with use: %s' % (datetime.now() - start)) def bar(): a, b, c = 1, 2, 3 function(a=77, b=b) start = datetime.now() for _ in range(c): bar() print('time with standard kwargs: %s' % (datetime.now() - start)) def baz(): a, b, c = 1, 2, 3 function(77, b) start = datetime.now() for _ in range(c): baz() print('time with positional args: %s' % (datetime.now() - start))

I saw now that I missed the biggest problem with your proposal: yet again you deliberately throw away errors. I'm talking about making Python code _less_ error prone, while you seem to want to make it _more_.

Beyond the belligerent tone, is there an actual POINT here?

Yes, there is a point: you keep insisting that I shut up about my ideas and you motivate it by giving first totally broken code, then error prone and slow code and then you are upset that I point out these facts. I think it's a bit much when you complain about the tone after all that. Especially after you wrote "If someone steps out of line of being polite and professional, just ignore it" the 9th of September in this very thread.

It's the middle of the night and I'm on my tablet.

Maybe you could just reply later?

I'm not sure what sort of error, or in what circumstance, my toy code "throws away" errors. Actually saying so rather than playing a coy guessing game would be helpful.

You explicitly wrote your code so that it tries to pass a local variable "d" that does not exist and the function does not take, and it doesn't crash on that. I guess you forgot? You've done it several times now and I've already pointed this out.

So for CPython 3.6 it's 2.587355/0.003079 = 840x times slower and pypy: 1.177555/0.002565 = 460x slower

Yes, for functions whose entire body consists of `pass`, adding pretty much any cost to unpacking the arguments will show down the operation a lot.

If you add sleep(0.001) it's still a factor 1.3! This is NOT a trivial overhead.

Changing the basic syntax of Python to optimize NOOPs really is a non-starter.

This is not a belligerent tone you think?

In general, changing syntax at all to avoid something easily accomplished with existing forms is—and should be—a very high barrier to cross.

Sure. I'm not arguing that it should be a low barrier, I'm arguing that it's worth it. And I'm trying to discuss alternatives.

I haven't used macropy. I should play with it. I'm guessing it could be used to create a zero-cost `use()` that had exactly the same API as my toy `use()` function. If so, you could starting using and publishing a toy version today and provide the optimized version as an alternative also.

Let me quote my mail from yesterday: "3. I have made a sort-of implementation with MacroPy: https://github.com/boxed/macro-kwargs/blob/master/test.py I think this is a dead end, but it was easy to implement and fun to try!" Let me also clarify another point: I wanted to open up the discussion to people who are interested in the general problem and just discuss some ideas. I am not at this point trying to get a PEP through. If that was my agenda, I would have already submitted the PEP. I have not. / Anders

Oh, I see that you indeed implemented a macropy version at https://github.com/boxed/macro-kwargs/blob/master/test.py. Other than use() vs grab() as the function name, it's the same thing. Is it true that the macro version has no performance cost? So it's now perfectly straightforward to provide both a function and a macro for grab(), and users can play with that API, right? Without changing Python, programmers can use this "shortcut keyword arguments corresponding to local names." On Wed, Sep 26, 2018, 5:31 AM David Mertz wrote:

On Wed, Sep 26, 2018, 5:12 AM Anders Hovmöller wrote:

...

I saw now that I missed the biggest problem with your proposal: yet again

...

you deliberately throw away errors. I'm talking about making Python code _less_ error prone, while you seem to want to make it _more_.

Beyond the belligerent tone, is there an actual POINT here?

Yes, there is a point: you keep insisting that I shut up about my ideas and you motivate it by giving first totally broken code, then error prone and slow code and then you are upset that I point out these facts. I think it's a bit much when you complain about the tone after all that. Especially after you wrote "If someone steps out of line of being polite and professional, just ignore it" the 9th of September in this very thread.

That's fine. I'm not really as bothered by your belligerent tone as I'm trying to find the point underneath it.

I guess... and I'm just guessing from your hints... that you don't like the "default to None" behavior of my *TOY* code. That's fine. It's a throwaway demonstration, not an API I'm attached to.

You're new here. You may not understand that, in Python, we have a STRONG, preference for doing things with libraries before changing syntax. The argument that one can do something using existing, available techniques is prima facie weight against new syntax. Obviously there ARE times when syntax is added, so the fact isn't an absolute conclusion.

But so far, your arguments have only seemed to amount to "I (Anders) like this syntax." The supposed performance win, the brevity, and the hypothetical future tooling, are just hand waving so far.