I can be wrong, but for what I know, `del variable_name` does not optimize the code, in the sense of performance. On the contrary, it should slow it down, since it simply removes the binding between the variable name from the namespace, allowing the gc to free the memory if that variable was the last reference to the object.
In a for and a list comprehension, I suppose it's unneeded, since the variable points automatically to another memory location, so the reference is removed automatically. Furthermore, if you want to delete a temporary variable, you could do: bc = b * c a = bc + d del bc but if bc is not a very big object, I suspect it will simply slow down the program. On Thu, 12 Mar 2020 at 16:06, Eric Wieser <wieser.eric+nu...@gmail.com> wrote: > > TL;DR: should we make `del x` an expression that returns the value of `x`. > > ## Motivation > > I noticed yesterday that `itertools.combinations` has an optimization for > when the returned tuple has no remaining ref-counts, and reuses it - namely, > the following code: > > >>> for v in itertools.combinations([1, 2, 3], 1): > ... print(id(v)) > ... del v # without this, the optimization can't take place > 2500926199840 > 2500926199840 > 2500926199840 > > will print the same id three times. However, when used as a list > comprehension, the optimization can't step in, and I have no way of using the > `del` keyword > > >>> [id(v) for v in itertools.combinations([1, 2, 3], 1)] > [2500926200992, 2500926199072, 2500926200992] > > `itertools.combinations` is not the only place to make this optimization - > parts of numpy use it too, allowing > > a = (b * c) + d > > to elide the temporary `b*c`. This elision can't happen with the spelling > > bc = b * c > a = bc + d > > My suggestion would be to make `del x` an expression, with semantics "unbind > the name `x`, and evaluate to its value". > This would allow: > > >>> [id(del v) for v in itertools.combinations([1, 2, 3], 1)] > [2500926200992, 2500926200992, 2500926200992] > > and > > bc = b * c > a = (del bc) + d # in C++, this would be `std::move(bc) + d` > > ## Why a keyword > > Unbinding a name is not something that a user would expect a function to do. > Functions operate on values, not names, so `move(bc)` would be surprising. > > ## Why `del` > > `del` already has "unbind this name" semantics, and allow it to be used as an > expression would break no existing code. > > `move x` might be more understandable, but adding new keywords is expensive > > ## Optional extension > > For consistency, `x = (del foo.attr)` and `x = (del foo[i])` could also > become legal expressions, and `__delete__`, `__delattr__`, and `__delitem__` > would now have return values. Existing types would be free to continue to > return `None`. > _______________________________________________ > 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/WVQNATE7KYU5G64BQB5VEWALPYVS3QPV/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ 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/7AD77HYSY4USGGVEABHWO4NQV3OVVOZB/ Code of Conduct: http://python.org/psf/codeofconduct/
