[issue44665] asyncio.create_task() documentation should mention user needs to keep reference to the task

2021-10-22 Thread Chris Meyer


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

2021-10-12 Thread Chris Meyer


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

2021-10-12 Thread Chris Meyer


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

2020-11-11 Thread Chris Meyer


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

2020-11-11 Thread Chris Meyer

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

2020-11-11 Thread Chris Meyer


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

2020-07-16 Thread Chris Meyer


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

2020-05-29 Thread Chris Meyer


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

2020-05-11 Thread Chris Meyer


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

2020-05-04 Thread Chris Meyer


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?

2020-04-21 Thread Chris Meyer


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

2020-04-20 Thread Chris Meyer


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

2020-04-20 Thread Chris Meyer


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

2020-04-20 Thread Chris Meyer


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

2020-04-20 Thread Chris Meyer


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

2016-10-17 Thread Chris Meyer

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