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
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), ye
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
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
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
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 aliv
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).
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 the
Allan Feldman 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
___
Python tracker
<https://bugs.python.or
Allan Feldman 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 tracker
<https://bugs.python.
New submission from Allan Feldman :
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. _asdict) would return the
11 matches
Mail list logo