Andrew Svetlov added the comment:
New changeset 2f2f9d0b5c96e68ed91cddd6673860ee752eb49c by Nick Crews in branch
'master':
bpo-15450: Allow subclassing of dircmp (GH-23424) (#23424)
https://github.com/python/cpython/commit/2f2f9d0b5c96e68ed91cddd6673860ee752eb49c
--
nosy:
Andrew Svetlov added the comment:
Thus using bare TimeoutError in asyncio is safe, isn't it?
This is good news!
--
___
Python tracker
<https://bugs.python.org/is
Andrew Svetlov added the comment:
I know that I just create OSError() with errno set to None.
My question is: has the standard library such code examples already?
In other words, how many third-party code will be broken by catching OSError
with errno=None
Andrew Svetlov added the comment:
Perhaps it is a good compromise.
OSError-derived class without errno looks getter to me that different
incompatible TimeoutError classes.
How many exceptions inherited from OSError have no errno set? Do we have a
precedent in stdlib at all already
Andrew Svetlov added the comment:
In futures and asyncio TimeoutError has no errno.
I'm not sure should we care but I consider it as a show stopper.
On another hand, two distinct timeout classes confuse people. I had many
conversions about this during the aiohttp support. asyncio can
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
Could you explain the proposal?
How "+X:UseContainerSupport" behaves for Java? Sorry, I did not use Java for
ages and don't follow the modern Java best practices.
>From my understanding, without the Docker the allocation of `bytearray(
Andrew Svetlov added the comment:
Perfect!
We have a consensus now and waiting for a champion who propose a Pull Request.
--
___
Python tracker
<https://bugs.python.org/issue42
Andrew Svetlov added the comment:
Perhaps Kyle is right, I had a misunderstanding with `get_running_loop()` vs
`_get_running_loop()`.
The last version seems good except for the rare chance of race condition.
The safe code can look like:
global_lock = threading.Lock() like GIL
def
Andrew Svetlov added the comment:
Is anything left to do?
--
___
Python tracker
<https://bugs.python.org/issue42085>
___
___
Python-bugs-list mailing list
Unsub
Andrew Svetlov added the comment:
Despite the fact that asyncio.get_running_loop() never returns None but raises
RuntimeError (and maybe other tiny cleanups),
I can live with the proposal.
It doesn't make a system worse at least and backward compatible.
We can return to the idea of ra
Andrew Svetlov added the comment:
My initial thought was protecting the Lock (and other primitives) creation when
a loop is not running.
Yuri insists that Lock can be created without a loop. Technically it is
possible, sure.
But the lock is tightly coupled with a loop instance. In other
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10
___
Python tracker
<https://bugs.python.or
Change by Andrew Svetlov :
--
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue42395>
___
___
Python-bugs-list mailing list
Unsubscribe:
Andrew Svetlov added the comment:
This was on my to-do list but I very much appreciate if somebody champions this
issue.
I should finish sslproto PR first.
--
___
Python tracker
<https://bugs.python.org/issue42
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset f37628eb7117f222de24a6931aa7639e668cb7b0 by Jakub Stasiak in
branch '3.8':
[3.8] bpo-42237: Fix os.sendfile() on illumos (GH-23154). (GH-23246)
https://github.com/python/cpython/commit/f37628eb7117f222de24a6931aa763
Andrew Svetlov added the comment:
New changeset fd4ed57674c675e05bd5d577dd5047a333c76c78 by Jakub Stasiak in
branch 'master':
bpo-42237: Fix os.sendfile() on illumos (GH-23154)
https://github.com/python/cpython/commit/fd4ed57674c675e05bd5d577dd5047a333c76c78
--
nosy:
Andrew Svetlov added the comment:
I believe, yes
--
status: pending -> open
___
Python tracker
<https://bugs.python.org/issue6225>
___
___
Python-bugs-lis
Andrew Svetlov added the comment:
Thank you Victor for the report!
--
___
Python tracker
<https://bugs.python.org/issue42085>
___
___
Python-bugs-list mailin
Andrew Svetlov added the comment:
PR for the fix is created: https://github.com/python/cpython/pull/23237
--
___
Python tracker
<https://bugs.python.org/issue42
Change by Andrew Svetlov :
--
pull_requests: +22135
pull_request: https://github.com/python/cpython/pull/23237
___
Python tracker
<https://bugs.python.org/issue42
Andrew Svetlov added the comment:
Investigating. The test leaks a future instance.
--
___
Python tracker
<https://bugs.python.org/issue42085>
___
___
Python-bug
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10
___
Python tracker
<https://bugs.python.or
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.7
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset 42d873c63aa9d160c132be4a34599531574db12c by Andrew Svetlov in
branch 'master':
bpo-42183: Fix a stack overflow error for asyncio Task or Future repr()
(GH-23020)
https://github.com/python/cpython/commit/42d873c63aa9d160c132be4a345995
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset a117167d8dc8fa673a4646f509551c7950f824e5 by Tom Gringauz in
branch 'master':
bpo-41543: contextlib.nullcontext can fill in for an async context manager
(GH-21870)
https://github.com/python/cpyt
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.9
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset 178695b7aee7a7aacd49a3086060e06347d1e556 by Kazantcev Andrey in
branch 'master':
bpo-40816 Add AsyncContextDecorator class (GH-20516)
https://github.com/python/cpython/commit/178695b7aee7a7aacd49a3086060e06347d1e556
--
nosy:
Andrew Svetlov added the comment:
New changeset ad37c66adcd474e3d42a51c63ecb6a54ca2d23f2 by Jakub Stasiak in
branch '3.8':
[3.8] bpo-42230: Improve asyncio documentation regarding accepting sets vs
iterables (GH-23073) (GH-23105)
https://github.com/python/cpyt
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset 3d86d090dcbbdfdd3e5a5951cab30612d6131222 by Jakub Stasiak in
branch 'master':
bpo-42230: Improve asyncio documentation regarding accepting sets vs iterables
(GH-23073)
https://github.com/python/cpyt
Andrew Svetlov added the comment:
The fix is ready
--
___
Python tracker
<https://bugs.python.org/issue42183>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Andrew Svetlov :
--
keywords: +patch
pull_requests: +21934
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23020
___
Python tracker
<https://bugs.python.org/issu
Change by Andrew Svetlov :
--
type: -> crash
versions: +Python 3.10, Python 3.7
___
Python tracker
<https://bugs.python.org/issue42183>
___
___
Python-
Andrew Svetlov added the comment:
Update: the bug is present in all supported Python versions bug sometimes may
be hidden by race conditions.
--
___
Python tracker
<https://bugs.python.org/issue42
Andrew Svetlov added the comment:
I cannot reproduce on 3.9 but 3.8.6 crashes on `repr`:
File
"/home/andrew/.pyenv/versions/3.8.6/lib/python3.8/asyncio/base_futures.py",
line 31 in format_cb
File
"/home/andrew/.pyenv/versions/3.8.6/lib/python3.8/asyncio/base_futures.p
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset c3442fd8a7f6e34ba888efea085c3701b75c0b71 by Miss Skeleton (bot)
in branch '3.9':
bpo-41959: Fix grammar around class asyncio.MultiLoopChildWatcher text
(GH-22580) (#22865)
https://github.com/python/cpyt
Andrew Svetlov added the comment:
Python is a volunteer-driven project.
The documentation translation is provided by champions who does this hard work
for free.
You can join the team and maintain the Python Russian Translation :)
Sorry, to keep the discussion productive I should remind our
Andrew Svetlov added the comment:
Thank you very much, Ned!
--
___
Python tracker
<https://bugs.python.org/issue33786>
___
___
Python-bugs-list mailin
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
The allowance to wait for the future object multiple times is settled in stone.
This cannot be changed without breaking very many codes.
So yes, asyncio guarantees that the feature is settled in stone. If set_value()
/ set_exception() was called, the value
Andrew Svetlov added the comment:
Remi is correct.
Closing the issue.
--
___
Python tracker
<https://bugs.python.org/issue41242>
___
___
Python-bugs-list mailin
Change by Andrew Svetlov :
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
I agree with Yuri.
Usually, you don't need overriding of the default exception handler.
Indeed, if you really need this low-level API I see nothing wrong with
`asyncio.get_running_loop()` call.
--
___
P
Andrew Svetlov added the comment:
Would somebody be a champion for the issue?
--
___
Python tracker
<https://bugs.python.org/issue39148>
___
___
Python-bug
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset 4482337decdbd0c6e2150346a68b3616bda664aa by Lidi Zheng in branch
'master':
bpo-39764: Make Task.get_stack accept ag_frame (#18669)
https://github.com/python/cpython/commit/4482337decdbd0c6e2150346a68b36
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
Other threads are not related.
Speaking about the main thread that runs an event loop with the signal handler
installed -- the handler is executed along with other async code.
If the loop executes some user-provides async task -- it executes the signal
Andrew Svetlov added the comment:
Assuming you mean loop.add_signal_handler() method, I would say that a
minute-long delay is a sign of long blocking calls in your program.
Typical asyncio program blocks the loop for 1-10 milliseconds at most, and
signal handlers are called with this delay
Andrew Svetlov added the comment:
I'm sorry. but loop.set_signal_handler() method doesn't exist.
--
___
Python tracker
<https://bugs.python.o
Andrew Svetlov added the comment:
I consider a free type for the default as an implementation detail, not the
encouraged approach.
Since the value is always a string, using the same type for the default sounds
like a sane design for me.
--
nosy: +asvetlov
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
This is a very interesting question.
In asyncio, task cancellation is not executed on `task.cancel()` call
immediately but the task is *marked* for cancellation.
The actual cancellation requires a context switch (await asyncio.sleep(0) or
similar) to
Andrew Svetlov added the comment:
asyncio doesn't kill subprocess by timeout, that's why test1() doesn't work.
The kill is done by signal sending which is asynchronous. That's why test2 may
fail at "FAIL(3)" point sometimes.
1-second sleep is enough to stop t
Andrew Svetlov added the comment:
The behavior is intentional and follows asyncio.run() semantics.
Moreover, every test should have a separate event loop instance, this is
stressed by IsolatedAsyncioTestCase class name
--
resolution: -> wont fix
stage: -> resolved
status
Andrew Svetlov added the comment:
Thanks, Ido
--
___
Python tracker
<https://bugs.python.org/issue39128>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
For server applications, the reverse proxy in front of the application can
limit the connection limit.
It is a good workaround because the proxy is required (and most likely is used
already) for any non-trivial server app
Andrew Svetlov added the comment:
I'm not sure.
Logging can pollute the logger and make it almost useless.
Most of mentioned errno codes are programming errors, a few may happen due
network issues.
Would you share what reasons did you ob
Andrew Svetlov added the comment:
>From my understanding, the issue is still desirable but we have a lack of
>resources.
Regarding the patch for tornado, using selectors.SelectSelector for
implementing add_reader()/remove_reader() and add_writer()/remove_writer() in
ProactorEventLoop
Andrew Svetlov added the comment:
The second solution doesn't help with breaking infinite loops like
while True:
pass
We need a more robust idea.
--
___
Python tracker
<https://bugs.python.org/is
Andrew Svetlov added the comment:
Not so easy to find a satisfactory generic approach.
An argument can also be 10 MiB length bytes array, a dictionary with 10,000
elements, HTML page, name it.
All these objects are printable but their representation is too verbose.
Task can have a dozen of
Andrew Svetlov added the comment:
The ship has sailed, this change breaks a lot of existing code without a strong
reason.
I recall very many cases in third-party libraries and commercial applications
where a negative argument for asyncio.sleep() is processed as asyncio.sleep(0)
without
Andrew Svetlov added the comment:
Victor, sorry.
I spent about 4 days in total trying to figure out what is the reason for
hanging.
I see that the signal handler is installed; but, in a rare situation, it is not
called when the process is killed.
If I reduce an amount of code executed in a
Change by Andrew Svetlov :
--
keywords: +patch
pull_requests: +17831
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18457
___
Python tracker
<https://bugs.python.org/issu
Change by Andrew Svetlov :
--
assignee: -> asvetlov
nosy: +asvetlov
___
Python tracker
<https://bugs.python.org/issue34788>
___
___
Python-bugs-list mai
Change by Andrew Svetlov :
--
nosy: -asvetlov
___
Python tracker
<https://bugs.python.org/issue10572>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Andrew Svetlov :
--
components: +asyncio
nosy: +yselivanov
___
Python tracker
<https://bugs.python.org/issue39529>
___
___
Python-bugs-list mailin
Andrew Svetlov added the comment:
Serhiy, maybe I had not understood your proposal properly.
If you are asking about deprecating get_event_loop() call from outside of async
code but implicit call get_running_loop() without a warning if called from
async function -- it sounds like a
Andrew Svetlov added the comment:
Currently, I'm talking about adding a deprecation only.
The asyncio.get_event_loop() function will stay in Python for a while in
deprecated status. I don't know the exact period but it should be 3 releases at
least I guess, with possibly exte
New submission from Andrew Svetlov :
Yuri proposed it for Python 3.8 but at that time the change was premature.
Now we can reconsider it for 3.9
The problem is that asyncio.get_event_loop() not only returns a loop but also
creates it on-demand if the thread is main and the loop doesn't
Change by Andrew Svetlov :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39483>
___
___
Python-bugs-
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset 90d9ba6ef10af32e8dfe0649789c3a8ccf419e95 by Andrew Svetlov in
branch 'master':
bpo-34793: Drop old-style context managers in asyncio.locks (GH-17533)
https://github.com/python/cpython/commit/90d9ba6ef10af32e8dfe0649789c3a
Andrew Svetlov added the comment:
Explicit error is better than error-prone design.
Think that we will deprecate asyncio.get_event_loop() and the loop
instantiation on-demand in the main thread.
--
resolution: -> rejected
stage: patch review -> resolved
status: open -&g
Andrew Svetlov added the comment:
A client that creates a loop implicitly in the constructor is a weird design
from my perspective.
You are free to use it, sure -- but please let us keep the freedom to not
support such corner cases by asyncio.run()
Sorry, I don't know the telethon li
Andrew Svetlov added the comment:
-1.
I rather suggest updating telethon example in the following matter:
async with main():
with TelegramClient('anon', api_id, api_hash) as client:
await client.send_message('me', 'Hello, myself!')
You PR brings more
Andrew Svetlov added the comment:
Serhiy is right, I doubt if we can do something here.
A function address is a part of its __repr__() output.
--
nosy: +asvetlov
___
Python tracker
<https://bugs.python.org/issue39
Andrew Svetlov added the comment:
The latest example releases allocated python objects.
The memory is returned to allocator which, in turn, can hold it for a while.
The allocator is not controlled by Python API.
Anyway, if an explicit executor solves your needs -- please just use it
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Andrew Svetlov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Andrew Svetlov added the comment:
New changeset a96e06db77dcbd3433d39761ddb4615d7d96284a by Andrew Svetlov in
branch 'master':
bpo-39386: Prevent double awaiting of async iterator (GH-18081)
https://github.com/python/cpython/commit/a96e06db77dcbd3433d39761ddb461
Change by Andrew Svetlov :
--
keywords: +patch
pull_requests: +17473
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18081
___
Python tracker
<https://bugs.python.org/issu
Change by Andrew Svetlov :
--
title: getting invalid data from async iterator -> Prevent double awaiting of
async iterator
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issu
Andrew Svetlov added the comment:
Thanks for the report.
Your example could be boiled down to the following:
coro = asynciter()
await coro
await coro
The second call incorrectly returns None but should raise an exception, double
awaiting is a programming error.
For regular async functions
Change by Andrew Svetlov :
--
keywords: +patch
pull_requests: +17446
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18051
___
Python tracker
<https://bugs.python.org/issu
New submission from Andrew Svetlov :
The current documentation says: "If there is no current event loop set in the
current OS thread and set_event_loop() has not yet been called, asyncio will
create a new event loop and set it as the current one."
https://docs.python.org/3.7/libra
Andrew Svetlov added the comment:
Thanks for sharing, your project looks viable!
--
___
Python tracker
<https://bugs.python.org/issue8800>
___
___
Python-bug
Andrew Svetlov added the comment:
FYI, I'm able to reproduce the hang by running "python -m test -F test_asyncio
-m test_close_kill_running".
Working on the fix.
--
___
Python tracker
<https://bugs.pyt
Andrew Svetlov added the comment:
I'd like to spend time by reproducing the issue locally.
Please give me a few days.
--
___
Python tracker
<https://bugs.python.org/is
Change by Andrew Svetlov :
--
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue38356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Andrew Svetlov added the comment:
I hope it is fixed now.
Thanks, Kyle!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Andrew Svetlov :
--
Removed message: https://bugs.python.org/msg359576
___
Python tracker
<https://bugs.python.org/issue39257>
___
___
Python-bug
Andrew Svetlov added the comment:
asyncio exception handler is supposed to catch *unhandled* exceptions only, not
all raised ones.
The first two cases from your example propagate raised exceptions to the
caller, these exceptions are unwound in a regular manner.
So, no need to call the
Change by Andrew Svetlov :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39191>
___
___
Pyth
501 - 600 of 2519 matches
Mail list logo