[issue38599] Deprecate creation of asyncio object when the loop is not running

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Fixed by #42392

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
superseder:  -> remove the deprecated 'loop' parameter asyncio API
versions: +Python 3.10 -Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Emmanuel Arias]

Change by Emmanuel Arias :


--
pull_requests: +17576
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18195

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Joongi Kim]

Joongi Kim  added the comment:

It is also generating deprecation warning:

> /opt/python/3.8.0/lib/python3.8/asyncio/queues.py:48: DeprecationWarning: The 
> loop argument is deprecated since Python 3.8, and scheduled for removal in 
> Python 3.10.
>   self._finished = locks.Event(loop=loop)

--
nosy: +achimnol

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Emmanuel Arias]

Emmanuel Arias  added the comment:

Hi, 

@asvetlov are you thinking something like the patch attached?

--
keywords: +patch
Added file: 
https://bugs.python.org/file48697/0001-Add-a-deprectation-warning-for-queue-w-o-event-runni.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Emmanuel Arias]

Change by Emmanuel Arias :


--
nosy: +eamanu

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Callum Ward]

Callum Ward  added the comment:

Hi, I'm a new contributor and this issue looks like an interesting enhancement: 
is there any consensus forming on what we want to limit to e.g. raising 
depreciation warnings when these first-class classes are created without 
running event loop?

--
nosy: +callumquick

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I'm pretty happy with asyncio.run() functionalit.

I used run() for the bug demonstration, but the example can be rewritten easily 
without this function.

The problem is not in run() but in an object lifecycle. Implicit loop creation 
plus module-level initialization provides a pretty big set of ways to shoot in 
the foot :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Yury Selivanov]

Yury Selivanov  added the comment:

> Well, I'm basically using a run method defined as a shorthand for 
> self.loop.run_until_complete (without closing loop, reusing it throughout). 
> It would be nice if asyncio.run could simply be used instead, but I 
> understand you're saying this is easier said than done, which is fine with 
> me. Thanks.

Yes. `asyncio.run()` is similar to `loop.run_until_complete()` but adds some 
guarantees + sane setup/cleanup. If we strip proper cleanup then there's no 
point in `asyncio.run()`.  So using `loop.run_until_complete()` is totally fine 
when you want to preserve the event loop between runs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Berry Schoenmakers]

Berry Schoenmakers  added the comment:

Well, I'm basically using a run method defined as a shorthand for 
self.loop.run_until_complete (without closing loop, reusing it throughout). It 
would be nice if asyncio.run could simply be used instead, but I understand 
you're saying this is easier said than done, which is fine with me. Thanks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Yury Selivanov]

Yury Selivanov  added the comment:

> It would be nice if asyncio.run() uses the default loop if it's available 
> (and not running), and that the default loop remains intact after the call 
> returns. 

Unfortunately it's not possible to implement that reliably and without a bunch 
of surprising behaviors.

Also, if you want the loop to be intact after asyncio.run, it means that you 
would not want to close it;that would defeat the purpose of asyncio.run.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Berry Schoenmakers]

Berry Schoenmakers  added the comment:

The current implementation of asyncio.run() is focused quite a bit on one-shot 
use. After the call returns, the default event loop is even gone: calling 
asyncio.get_event_loop() gives "RuntimeError: There is no current event loop in 
thread 'MainThread'."

It would be nice if asyncio.run() uses the default loop if it's available (and 
not running), and that the default loop remains intact after the call returns. 

This way multiple calls to asyncio.run() that all use the default loop are 
supported, maybe using an asyncio.Queue (or whatever) across these 
calls---attaching everything to the same (default) loop.

I find this very useful, for instance when writing unit tests.

--
nosy: +lschoe

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Andrew Svetlov]

Andrew Svetlov  added the comment:

At least it is my learned lesson from aiohttp development.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I have a different feeling: we should start raising deprecation for 
asyncio.Queue() if it is created without running event loop.

It required `get_event_loop()` and `loop.is_running()` checks.

Later the pair can be replaced with `get_running_loop()`.

I think no check at awaiting time is needed; we never do it for other asyncio 
parts.  Just control of the loop at creation time is enough; if the object is 
created inside a running loop the sane code will use it with this loop context 
always.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Yury Selivanov]

Yury Selivanov  added the comment:

Yes.

As a remedy for this particular problem we can add checks here and there 
comparing `asyncio.get_running_loop()` and `self._loop`.  Performance will 
suffer a bit but the usability will greatly improve.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Andrew Svetlov]

New submission from Andrew Svetlov :

Consider the following code:

import asyncio

q = asyncio.Queue()

async def main():
await asyncio.gather(q.put(1), q.get(1))

asyncio.run(main())


This code just hangs since run() creates a loop but queue is bound with another 
(default) event loop.

The error is confusing and hard-to-debug.

We should raise a warning at least for the case; start from DeprecationWarning 
and make the system stricter later.

asyncio/locks.py is also affected since it has first-class classes (classes 
that instantiated by a user directly without factories).

--
components: asyncio
messages: 355449
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate creation of asyncio object when the loop is not running
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com