[issue44665] asyncio.create_task() documentation should mention user needs to keep reference to the task
Chris Meyer added the comment: Is there a way to reproduce this issue? I run the following code in Python 3.9 and it works as expected (prints "xyz" twice). import asyncio import gc async def xyz(): print("xyz") event_loop = asyncio.get_event_loop() event_loop.create_task(xyz()) t = event_loop.create_task(xyz()) del t gc.collect() event_loop.stop() event_loop.run_forever() -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue44665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45454] Unable to explicitly subclass protocol when subclass has mixin requiring init
Chris Meyer added the comment: This looks like it a regression specific to Python 3.9.7 and has been fixed. https://bugs.python.org/issue45081 https://github.com/python/cpython/pull/28132. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45454] Unable to explicitly subclass protocol when subclass has mixin requiring init
New submission from Chris Meyer : If I make a explicit subclass of a protocol that also inherits from a mixin and calls super() in order to initialize the mixin, I get the "Protocols cannot be instantiated" exception. This case arises when having a hierarchy of both protocols and concrete classes that implement the protocols. A simple example is: import typing class P(typing.Protocol): def m1(self) -> None: ... class M: def __init__(self) -> None: super().__init__() self.o = True class C(M, P): def __init__(self) -> None: super().__init__() self.op = True def m1(self) -> None: pass c = C() I can resolve this in particular cases by not invoking super in the mixin or putting a special no-super class in the hierarchy. However, that is not a general solution and once the class hierarchy gets more complicated, it fails to work. Am I missing any known solution to this issue? -- components: Library (Lib) messages: 403782 nosy: cmeyer priority: normal severity: normal status: open title: Unable to explicitly subclass protocol when subclass has mixin requiring init type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42260] [C API] Add PyInterpreterState_SetConfig(): reconfigure an interpreter
Chris Meyer added the comment: >> I would like to request that this ability to dynamically load Python DLLs >> remains even with any new initialization mechanism. > I don't plan to remove any feature :-) I am glad to hear that. I'm somewhat nervous about it nevertheless. In particular, the implementation of Py_DECREF changed from 3.7 to 3.8 to 3.9. 3.7 worked entirely in a header; but 3.8 had a quirky definition of _Py_Dealloc which used _Py_Dealloc_inline but was defined out of order (used before defined). This was somewhat addressed in https://github.com/python/cpython/pull/18361/files; however 3.9 now has another mechanism that defines _Py_Dealloc in Objects/object.c. This isn't a major problem because it has the same implementation as before, but changes like this have the potential to make the launcher binary be version specific. Again, not a deal breaker, but it still makes me nervous. -- ___ Python tracker <https://bugs.python.org/issue42260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42260] [C API] Add PyInterpreterState_SetConfig(): reconfigure an interpreter
Chris Meyer added the comment: > How do you configure sys.path currently? Do you parse a configuration file? > Do you use a registry key on Windows? We have several launch scenarios - but for the currently most common one, which is to launch using a separate, existing Python environment, we call Py_SetPythonHome and Py_SetPath with the home directory of the environment. Then, presumably, the more complete path gets set in either Py_Initialize or when we call PyImport_ImportModule(“sys”). I might have tracked the details down once, but I don't recall them. By the time our Python code starts running, sys.path is reasonably populated. However, in another scenario, we launch with an embedded Python environment, essentially a virtual environment. In that case, we have a config file to explicitly add lib, DLLs, and site packages. But something goes wrong [cannot find/load the unicode DLL IIRC] unless we call site.addsitedir for each directory already in sys.path near the start of our Python portion of code. My notes point to two issues to explain this: https://bugs.python.org/issue22213 and https://bugs.python.org/issue35706. -- ___ Python tracker <https://bugs.python.org/issue42260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42260] [C API] Add PyInterpreterState_SetConfig(): reconfigure an interpreter
Chris Meyer added the comment: Responding to your request for feedback on Python-Dev: We embed Python dynamically by finding the libPython DLL, loading it, and looking up the required symbols. We make appropriate define's so that the Python headers (and NumPy headers) point to our functions which in turn point to the looked up symbols. Our launcher works on Linux, macOS, and Windows and works with many environments including standard Python and conda and brew. It also supports virtual environments in most cases. Also, a single executable [per platform] is able to work with Python versions 3.7 - 3.9 (3.6 was recently dropped, but only for external reasons). So my comment is not directly addressing the usefulness of configuring Python initialization - but I would like to request that this ability to dynamically load Python DLLs remains even with any new initialization mechanism. As another note, the main issues we run into are configuring the Python path to properly find packages and DLLs. A goal of ours is to be able to provide the base application as a drag-and-drop style installer with its own full embedded Python distribution (but still loaded dynamically) and then be able to supply additional plug-in packages (Python packages) by drag and drop. This is somewhat similar to conda packaging but without support for command line tools. -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue42260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38856] asyncio ProactorEventLoop: wait_closed() can raise ConnectionResetError
Change by Chris Meyer : -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue38856> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
Change by Chris Meyer : -- keywords: +patch pull_requests: +19769 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20525 ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
Chris Meyer added the comment: Here is another way to reproduce this (or an extremely similar) error without a loop. Since may be a race condition, I'm not sure this works 100% of the time on all machines - but it did on several machines I tried. ``` import asyncio loop = asyncio.get_event_loop() def func(): pass f = loop.run_in_executor(None, func) loop.stop() loop.run_forever() loop.stop() loop.run_forever() loop.stop() loop.run_forever() ``` ``` Error on reading from the event loop self pipe loop: Traceback (most recent call last): File "C:\Miniconda3\envs\py38\lib\asyncio\windows_events.py", line 453, in finish_recv return ov.getresult() OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Miniconda3\envs\py38\lib\asyncio\proactor_events.py", line 768, in _loop_self_reading f.result() # may raise File "C:\Miniconda3\envs\py38\lib\asyncio\windows_events.py", line 808, in _poll value = callback(transferred, key, ov) File "C:\Miniconda3\envs\py38\lib\asyncio\windows_events.py", line 457, in finish_recv raise ConnectionResetError(*exc.args) ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request ``` -- ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39232] asyncio crashes when tearing down the proactor event loop
Change by Chris Meyer : -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue39232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40357] asyncio: will shutdown_default_executor work in single step (stop, run_forever) mode?
New submission from Chris Meyer : Is the new asyncio.loop.shutdown_default_executor() suitable for event loops that are run in single-step mode? event_loop.create_task(event_loop.shutdown_default_executor()) event_loop.stop() event_loop.run_forever() I don't see how it will work since shutdown_default_executor() may not be finished during a single 'stopped' run_forever() call. Also, what happens to pending executor futures? Previously reported bug #28464. Here is my currently working code for shutting down the event loop. # give event loop one chance to finish up event_loop.stop() event_loop.run_forever() # wait for everything to finish, including tasks running in executors # this assumes that all outstanding tasks finish in a reasonable time (i.e. no infinite loops). all_tasks_fn = getattr(asyncio, "all_tasks", None) if not all_tasks_fn: all_tasks_fn = asyncio.Task.all_tasks tasks = all_tasks_fn(loop=event_loop) if tasks: gather_future = asyncio.gather(*tasks, return_exceptions=True) else: # work around fact that gather always uses global event loop in Python 3.8 gather_future = event_loop.create_future() gather_future.set_result([]) event_loop.run_until_complete(gather_future) # due to a seeming bug in Python libraries, the default executor needs to be shutdown explicitly before the event loop # see http://bugs.python.org/issue28464 . _default_executor = getattr(event_loop, "_default_executor", None) if _default_executor: _default_executor.shutdown() event_loop.close() -- messages: 366945 nosy: cmeyer, vstinner priority: normal severity: normal status: open title: asyncio: will shutdown_default_executor work in single step (stop, run_forever) mode? versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40357> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads
Change by Chris Meyer : -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue34037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39010] ProactorEventLoop raises unhandled ConnectionResetError
Change by Chris Meyer : -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue39010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37373] Configuration of windows event loop for libraries
Change by Chris Meyer : -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue37373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39651] Exceptions raised by EventLoop.call_soon_threadsafe
Chris Meyer added the comment: Is this related to bpo-39010 too? -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue39651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28464] BaseEventLoop.close should shutdown executor before marking itself closed
New submission from Chris Meyer: BaseEventLoop.close shuts down the executor associated with the event loop. It should do that BEFORE it sets self._closed = True, otherwise any pending executor futures will attempt to 'call_soon' on the event loop when they finish, resulting in a confusing error message that the event loop is already closed. -- components: asyncio messages: 278829 nosy: cmeyer, gvanrossum, yselivanov priority: normal severity: normal status: open title: BaseEventLoop.close should shutdown executor before marking itself closed type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com