On 2016-10-21 6:29 AM, Steven D'Aprano wrote:
On Wed, Oct 19, 2016 at 05:52:34PM -0400, Yury Selivanov wrote:
[..]
With you proposal, to achieve the same (and make the code compatible
with new for-loop semantics), users will have to implement both
__iterclose__ and __del__.
As I ask above, couldn't we just inherit a default __(a)iterclose__ from
object that looks like this?
def __iterclose__(self):
finalizer = getattr(type(self), '__del__', None)
if finalizer:
finalizer(self)
I know it looks a bit funny for non-iterables to have an iterclose
method, but they'll never actually be called.
No, we can't call __del__ from __iterclose__. Otherwise we'd
break even more code that this proposal already breaks:
for i in iter:
...
iter.something() # <- this would be call after iter.__del__()
[..]
As for the amount of good, this proposal originally came from PyPy. I
expect that CPython users won't appreciate it as much as PyPy users, and
Jython/IronPython users when they eventually support Python 3.x.
AFAIK the proposal came "for" PyPy, not "from". And the
issues Nathaniel tries to solve do also exist in CPython. It's
only a question if changing 'for' statement and iteration protocol
is worth the trouble.
Yury
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
