[Python-ideas] Fwd: Keyword only argument on function call

Anders Hovmöller boxed at killingar.net
Wed Sep 26 06:44:38 EDT 2018


> Oh, I see that you indeed implemented a macropy version at https://github.com/boxed/macro-kwargs/blob/master/test.py <https://github.com/boxed/macro-kwargs/blob/master/test.py>.
> Other than use() vs grab() as the function name, it's the same thing.

Well, except that it's import time, and that you do get the tooling on the existence of the local variables. You still don't get any check that the function has the parameters you're trying to match with your keyword arguments so it's a bit of a half measure. 

Steve had a fun idea of using the syntax foo=☃ where you could transform ☃ to the real name at import time. It's similar to the MacroPy solution but can be implemented with a super tiny import hook with an AST transformation, and you get the tooling part the MacroPy version is missing, but of course you lose the parts you get with MacroPy. So again it's a half measure.. just the other half.

> Is it true that the macro version has no performance cost?

In python 2 pretty much since it's compile time, in python 3 no because MacroPy3 has a bug in how pyc files are cached (they aren't). But even in the python 3 case the performance impact is at import time so not really significant.

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

Sort of. But for my purposes I don't really think it's a valid approach. I'm working on a 240kloc code base (real lines, not comments and blank lines). I don't think it's a good idea, and I wouldn't be able to sell it ot the team either, to introduce macropy to a significant enough chunk of the code base to make a difference. Plus the tooling problem mentioned above would make this worse than normal kwarg anyway from a robustness point of view.

I'm thinking that point 4 of my original list of ideas (PyCharm code folding) is the way to go. This would mean I could change huge chunks of code to the standard python keyword argument syntax and then still get the readability improvement in my editor without affecting anyone else. It has the downside that you don't to see this new syntax in other tools of course, but I think that's fine for trying out the syntax.

The biggest problem I see is that I feel rather scared about trying to implement this in PyCharm. I've tried to find the code for soft line breaks to implement a much nicer version of that, but I ended up giving up because I just couldn't find where this happened in the code! My experience with the PyCharm code base is basically "I'm amazed it works at all!".

If you know anyone who feels comfortable with the PyCharm code that could point me in the right direction I would of course be very greatful!

/ Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180926/98c015b7/attachment-0001.html>


More information about the Python-ideas mailing list