> You can get the same effect by not naming the value being thrown away
This is absolutely true, although I don't think that's a particularly strong
argument against it. The same can be said of `std::move` in C++. The purpose
of this suggestion is primarily to allow introducing names without it coming at
the cost of unwanted reference counts. Consider the following expression, with
no intermediate names:
h = get_h_long_name(get_g_long_name(get_f_long_name(x))
With my proposal, this would become exactly equivalent to the following in
terms of reference counts
f = get_f_long_name(del x)
g = get_g_long_name(del f)
h = get_h_long_name(del g)
> Do you have an example of an application where this sort of
> micro-optimisation is significant enough to justify a fairly major language
> change?
As an example of these optimizations being valuable, see
https://github.com/numpy/numpy/pull/7997, which claims the optimization I
described at the beginning resulted in a 1.5x-2x speedup.
> but that didn't need a language change to implement...
The language change I'm proposing isn't about _implementing_ these
optimizations, it's about allowing users to exploit them without having to
sacrifice naming their variables.
Eric
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZR5LQTYVYQTC5C64WJDAETFFSVTL7D62/
Code of Conduct: http://python.org/psf/codeofconduct/
