On Wed, Sep 26, 2018, 3:19 AM Anders Hovmöller <bo...@killingar.net> 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? It's the middle of the night and I'm on my tablet. 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. > 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. I'm actually sightly surprised the win is not bigger in Pypy than in CPython. I'd kinda expect them to optimize away the entire call when a function call is a NOOP. Anyway, this is 100% consistent with what I said. For functions with actual bodies, the lookup is negligible. It could be made a lot faster, I'm sure, if you wrote `use()` in C. Probably even just by optimizing the Python version (`reach()` doesn't need to be a separate call, for example, it's just better to illustrate that way). Changing the basic syntax of Python to optimize NOOPs really is a non-starter. In general, changing syntax at all to avoid something easily accomplished with existing forms is—and should be—a very high barrier to cross. 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.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/