[issue41174] asyncio.coroutine decorator returns a non-generator function when using PYTHONASYNCIODEBUG

New submission from Allan Feldman : This code behaves differently when PYTHONASYNCIODEBUG=1 import asyncio import inspect @asyncio.coroutine def foo(): yield from asyncio.sleep(0) print("isgeneratorfunction:", inspect.isgeneratorfunction(foo)) PYTHONASYNCIODEBUG: isgenerat

[issue40312] Weakref callbacks running before finalizers in GC collection

Allan Feldman added the comment: Yup agree with all the points above, just wanted to point out that I think self.value is strongly referenced (even though it's just internal references and will be collected by the gc) during Foo.__del__ execution (annotated code below), yet

[issue40312] Weakref callbacks running before finalizers in GC collection

Allan Feldman added the comment: I definitely understand the possibility that some code is relying on the current gc behavior of weakref callbacks being invoked after finalizers. That being said, the behavior is currently inconsistent between gc and reference counted paths. The language

[issue40312] Weakref callbacks running before finalizers in GC collection

Allan Feldman added the comment: Also I just noticed this statement: > In current CPython, for your ForeverObject(False), `del o` does not make the > object trash "for real". __del__ runs immediately (due to deterministic, > synchronous reference counting) and resurrects

[issue40312] Weakref callbacks running before finalizers in GC collection

Allan Feldman added the comment: Thanks for the explanation! I agree that "about to be finalized" is unclear in the docs :) I still believe that having different behavior for the ordering of finalizers versus weakref callbacks depending on whether the path is through gc versus

[issue40312] Weakref callbacks running before finalizers in GC collection

Allan Feldman added the comment: Reading more carefully, I may have jumped to conclusions here :) Looking at the weakref docs, I see the following description of the callback functionality: > If callback is provided and not None, and the returned weakref object is > still

[issue40312] Weakref callbacks running before finalizers in GC collection

Allan Feldman added the comment: Thanks for the response! > if a weakref W refers to object O, and W and O are _both_ in cyclic trash I believe that in the examples W is not in cyclic trash, but remains referenced as a global in the frame. Only O is in cyclic trash (O references itself).

[issue40312] Weakref callbacks running before finalizers in GC collection

New submission from Allan Feldman : Our team is making use of a weakref.WeakValueDictionary() that is accessed through the finalizer of a class. We observed that in Python 3 occasionally values that are directly referenced by an object being finalized were missing from

[issue33380] Update module attribute on namedtuple methods for introspection.

Allan Feldman <allan.d.feld...@gmail.com> added the comment: That explanation makes sense to me. Thanks for taking the time to look into this! -- resolution: -> works for me stage: -> resolved status: open -> closed ___ Pyth

[issue33380] Update module attribute on namedtuple methods for introspection.

Allan Feldman <allan.d.feld...@gmail.com> added the comment: Attached is a proposed change. -- keywords: +patch Added file: https://bugs.python.org/file47555/0001-bpo-33380-Update-module-attribute-on-namedtuple-meth.patch ___ Python tracke

[issue33380] Update module attribute on namedtuple methods for introspection.

New submission from Allan Feldman <allan.d.feld...@gmail.com>: Python 3.7 made several performance improvements to the namedtuple class as part of https://bugs.python.org/issue28638 Prior to the implementation of bpo-28638, the __module__ attribute for a namedtuple's methods (e.g. _