A missing Py_DECREF on the future's "done" method
caused both the bound method and the underlying
self instance of the future to be leaked when
awaiting non-panda futures (such as _asyncio.Future).
This change includes a simple new test addition
to catch this in the future.
This adds persistent wrapper support (introduced by the previous commit) to PythonTask, which makes it possible for reference cycles involving tasks to be found and destroyed.
The major caveat is that it always creates a reference cycle. This can be broken automatically if there is no more Python reference to it by the time the last C++ reference is dropped, but the other way around requires the garbage collector.
For tasks, I think this it is generally the case that the last reference is in C++, since tasks are usually created and then handed off to the C++ task manager, and for applications that don't want to rely on the GC, it is easy to work around. If this turns out to be a problem, though, we can add a special garbage collection pass to the task manager.
This is more idiomatic, simplifies the code, makes it easier to port to eg. HPy later on, and makes it easier to use the limited ABI (where it can be optimized to a tail call) later on
A polyfill is provided for compatibility with Python versions 3.8 and 3.9
This is more useful and consistent; you can after all just use "return" to end the task, whereas you can now just use "yield" to continue the next frame rather than "yield Task.cont".
This is a follow-up to f6b39345f7, which already enabled this behavior when an __await__ (that is awaited from a task) yielded None.
This matches the behavior of asyncio's Task implementation, where this is the equivalent of `yield Task.cont`.
I've kept regular generator tasks unaffected for now, since this might break existing usage.
The intended purpose of this function is to restore an exception
that has already been raised and saved with PyErr_Fetch. It should
not be used to raise new exceptions nor should it be used to clear
the current exception.
The especially egregious example is
`PyErr_Restore(exc_type, nullptr, nullptr);`
as the null value may not be handled correctly.
This introduces AsyncFuture as a new base class of AsyncTask. It's modelled after asyncio's Future class, except that it is thread-safe and you can use result() to block the current thread waiting for the future to finish (of course this is not necessary for use with coroutines).
AsyncFuture should be used for any operation that finishes in the future, to get the benefit of awaitability within coroutines as well as a standard interface for querying status and results of the operation as well as cancelling it. As such, it's been implemented in various places, including texture.prepare() and win.trigger_copy().
Note that AsyncFuture is intended to be used *once*; it cannot be used more than once. As an example of how this works, tex.prepare() will return the same future as long as the prepare isn't complete, but when it is done, subsequent calls to tex.prepare() will return a new future.
* Better support for typedefs
* Same code should compile for both 32-bit and 64-bit
* C++11 typed enum support
* Synthesize __setitem__ when operator [] returns reference
* Rewrite coerce system to have better performance
* Change semantics of __getattr__ and __setattr__ to match
Python's, add __getattribute__, __delattr__ and __delitem__
* Improve performance of slot functions a bit more
* Reduce memory overhead of type system
* Some support for wrapping arrays of numeric types
* C++11 character type support in cppparser
* Chars are handled as strings of length 1
* Template functions for CreatePyInstance that use runtime type map
* More functions from dtool as extension functions
* Code cleanup
rdb
John C. Allwein
Daniel
Sam Edwards
tobspr