[issue38911] include __del__ in Generator ABC

Guido van Rossum added the comment: I wouldn't have use a Generator subclass for that. Let's not destabilize the Generator class. -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue38911] include __del__ in Generator ABC

Matt McEwen added the comment: My interpretation of issue 24018 was that the Generator ABC was trying to follow the PEP as much as possible, so that users were able to produce a custom generator object and have it behave just like a builtin generator object. I know that subclassing Generator

[issue38911] include __del__ in Generator ABC

Guido van Rossum added the comment: The PEP does not specify collections.Generator at all, so this is not just a matter of interpreting the PEP. The presence of a __del__ method can cause subtle behavior changes to the GC, so I worry that adding __del__ to that class now is going to break c

[issue38911] include __del__ in Generator ABC

Raymond Hettinger added the comment: Guido should decide this one. The PEP isn't entirely clear whether __del__ is a CPython implementation detail, nor is it clear whether the intent was for the isinstance() to insist on __del__ being present. Also, at one time __del__ interfered with garb

[issue38911] include __del__ in Generator ABC

Change by Roundup Robot : -- keywords: +patch pull_requests: +16866 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17384 ___ Python tracker ___ __

[issue38911] include __del__ in Generator ABC

New submission from Matt McEwen : The Generator ABC in the standard library lets users define objects that follow the Generator specification given in PEP342, and which can be used in the place of builtin generator objects. This was originally added in issue 24018 The ABC enforces that the