Alex Grönholm added the comment:
Yeah, I'm still interested. I'll create a new BPO when I have something.
--
___
Python tracker
<https://bugs.python.o
Alex Grönholm added the comment:
> I was under the impression that ExceptionGroup was somewhat backwards
> compatible, in that you could still use `except CancelledError:` and it would
> catch all the errors in the group. But, maybe I'm wrong, I've not seen the
> docum
Alex Grönholm added the comment:
> But, if we are using nonces on the CancelledError to keep track, then only 1
> context manager will know if it was themselves or not. This is exactly why
> I'm proposing to use multiple CancelledErrors, so that every nonce is passed
> to
Alex Grönholm added the comment:
> Propagating an ExceptionGroup where every exception can be inspected to see
> if it was caused by this code or not still seems like the safe option to me
> (and obviously still has the cancel count implicitly).
Note that this, too, causes
Alex Grönholm added the comment:
Yeah, my question was specific about the new functions, so I understood that a
separate PR should add that to the all the relevant functions.
I have a different problem now however: the test suite is failing in CI but not
locally. It's giving me Name
Alex Grönholm added the comment:
> It looks more complicated -- the extra parameter needs to be passed around
> via the task and then into the CancelledError exception.
It reduces overall complexity by making uncancellation unnecessary and
restoring backwards compatibility.
> What
Change by Alex Grönholm :
--
keywords: +patch
pull_requests: +29583
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31455
___
Python tracker
<https://bugs.python.org/issu
Alex Grönholm added the comment:
> Alex, the 'scope' argument can be added if it is really required.
> I'm not sure if the nonce is unavoidable still.
What other generic solution is there? I've read your last few messages but
didn't find an answer. There needs
Alex Grönholm added the comment:
Can I also get comments on my proposal for the "scope" parameter? Is there a
use case it would not solve?
--
___
Python tracker
<https://bugs.python.o
Alex Grönholm added the comment:
One question: should I add the "flags" argument to the new functions? For some
reason it's missing from the existing functions, so maybe I should add that in
a separate PR?
--
___
Python
New submission from Alex Grönholm :
The asyncio module currently has a number of low-level functions for working
asynchronously with raw socket objects. Such functions for working with UDP
sockets are, however, notably absent, and there is no workaround for this. You
can of course use
Alex Grönholm added the comment:
I propose the following, backwards compatible solution:
Add a new keyword argument to Task.cancel(): "scope: object = None".
The behavior would be as follows: the scope is saved, and included in the
raised CancelledError. If Task.cancel() is called
Alex Grönholm added the comment:
I am also uncomfortable using the cancel message to deliver the
token/nonce/whatever.
If TaskGroup.cancel() is implemented, would it also deliver a cancellation in
the parent task like trio and AnyIO do? It should IMHO, because otherwise if
the task group is
Alex Grönholm added the comment:
@Guido you asked for the AnyIO implementation of Happy Eyeballs; here it is:
https://github.com/agronholm/anyio/blob/ac3e7c619913bd0ddf9c36b6e633b278d07405b7/src/anyio/_core/_sockets.py#L85
(I didn't paste the actual code here because it's wa
Alex Grönholm added the comment:
I just tried to write a snippet to demonstrate the issue in TaskGroup, but that
doesn't seem possible since TaskGroup never swallows a CancelledError. It
always raises/propagates _some_ exception out of __aexit__() unless of course
all the child tasks r
Alex Grönholm added the comment:
Thanks, I will take a look at .uncancel() and .cancelling(). I saw that work
happening in my email feed but couldn't figure out right away how it helped,
but I will definitely look into the new TaskGroup code to see how it's used
there and will g
Alex Grönholm added the comment:
I'm not trying to argue that asyncio should be changed to have level
cancellation or even cancel scopes as built-in (at this point), but expanding
the low level API to make implementing these features possible in third party
libraries without the aw
Alex Grönholm added the comment:
A brief explanation of cancel scopes for the uninitiated: A cancel scope can
enclose just a part of a coroutine function, or an entire group of tasks. They
can be nested within each other (by using them as context managers), and marked
as shielded from
Alex Grönholm added the comment:
I just noticed that Ubuntu 22.04 LTS also uses OpenSSL 3 with their Python
builds. I hope somebody has told them too about the state of affairs.
--
___
Python tracker
<https://bugs.python.org/issue46
Alex Grönholm added the comment:
Good to see that this is being handled. I could try to write a patch to do what
I suggested above, if you're willing to review it.
--
___
Python tracker
<https://bugs.python.org/is
Alex Grönholm added the comment:
I hope the Fedora maintainers/packagers know this because on Rawhide, Python is
being compiled against OpenSSL 3 (which is how we discovered the problem). F36
is due out in a little over 3 months.
--
___
Python
Alex Grönholm added the comment:
This is a security issue because it exposes users to TLS truncation attacks
that weren't possible before because such attempts would raise SSLEOFError.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Alex Grönholm :
PR #25309 (https://github.com/python/cpython/pull/25309) changed OpenSSL
behavior so that it ignores unexpected EOFs by default. This was detected by
the test suites of both trio and AnyIO when running on OpenSSL 3.
We worked around the problem by
Change by Alex Grönholm :
--
nosy: +alex.gronholm
___
Python tracker
<https://bugs.python.org/issue40059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alex Grönholm added the comment:
OpenSSL 1.1.1 also handled EOFs strictly, but this behavior was generally
suppressed in the ssl module through the default setting of
suppress_ragged_eofs=True (thus enabling truncation attacks by default). The PR
changes the behavior of existing applications
Change by Alex Grönholm :
--
keywords: +patch
pull_requests: +21699
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22736
___
Python tracker
<https://bugs.python.org/issu
New submission from Alex Grönholm :
>>> DummyDict = TypedDict('DummyDict', {'x': int, 'y': str}, total=False)
>>> DummyDict.__required_keys__
frozenset({'x', 'y'})
This happens because the TypedDict function does not pass
Alex Grönholm added the comment:
My repro script also demonstrates that when binding to an interface, the bug is
not triggered.
--
___
Python tracker
<https://bugs.python.org/issue40
Alex Grönholm added the comment:
I just got hit by this bug too. Attached is the repro script I came up with
before finding this report.
--
nosy: +alex.gronholm
Added file: https://bugs.python.org/file49346/udptest.py
___
Python tracker
<ht
Change by Alex Grönholm :
--
keywords: +patch
pull_requests: +20734
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21595
___
Python tracker
<https://bugs.python.org/issu
Alex Grönholm added the comment:
Looks like they do – fantastic!
--
___
Python tracker
<https://bugs.python.org/issue41317>
___
___
Python-bugs-list mailin
Alex Grönholm added the comment:
Sure, it should be a rather straightforward fix. I have to check if the tests
for the related methods test for proper cancellation semantics. It should be
even faster if they do.
--
___
Python tracker
<ht
Change by Alex Grönholm :
--
nosy: +alex.gronholm
___
Python tracker
<https://bugs.python.org/issue31821>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Alex Grönholm :
--
keywords: +patch
pull_requests: +20671
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21533
___
Python tracker
<https://bugs.python.org/issu
New submission from Alex Grönholm :
The connect_accepted_socket() method seems to be missing from the
AbstractEventLoop ABC. I assume this was a simple mistake of omission. I will
ready a PR to add it.
--
components: asyncio
messages: 373904
nosy: alex.gronholm, asvetlov, yselivanov
Alex Grönholm added the comment:
This bug is the same as https://bugs.python.org/issue30064 except for
sock_accept().
--
___
Python tracker
<https://bugs.python.org/issue41
New submission from Alex Grönholm :
Unlike with all the other sock_* functions, sock_accept() only removes the
reader on the server socket when the socket becomes available for reading (ie.
when there's an incoming connection). If the operation is cancelled instead,
the reader is not re
Alex Grönholm added the comment:
I think the most important use case for these is closing async generators
deterministically, since they don't support the async context manager protocol.
--
___
Python tracker
<https://bugs.python.org/is
Alex Grönholm added the comment:
They are both still useful, particularly with third party libraries. Just
yesterday I found myself looking for aclosing() in contextlib, only to remember
this issue.
--
___
Python tracker
<https://bugs.python.
Alex Grönholm added the comment:
The PR is still awaiting for a core developer to be reviewed. It's too bad we
missed the 3.8.3 window, but perhaps this can get included in 3.9.0 at least.
--
___
Python tracker
<https://bugs.python.org/is
Alex Grönholm added the comment:
Has this effort gone forwards lately, or has there been any discussion
elsewhere? I implemented support for "Z" in .fromisoformat() before finding
this issue. Even after reading the discussion I still don't quite understand
why it'
Alex Grönholm added the comment:
Thanks, looks good to me now!
--
___
Python tracker
<https://bugs.python.org/issue39148>
___
___
Python-bugs-list mailin
Alex Grönholm added the comment:
Oh, it's https://github.com/python/cpython/pull/19121. I think it would be
prudent to add a test as well to make sure this doesn't happen again.
--
___
Python tracker
<https://bugs.python.o
Alex Grönholm added the comment:
Which PR is it?
--
___
Python tracker
<https://bugs.python.org/issue39148>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alex Grönholm added the comment:
Seconded.
--
nosy: +alex.gronholm
___
Python tracker
<https://bugs.python.org/issue40213>
___
___
Python-bugs-list mailin
Alex Grönholm added the comment:
Well, I found this:
https://github.com/python/cpython/blob/3c97e1e457033bbb8bbe0b7198bd13fc794a12b0/configure.ac#L3278-L3279
Could it be that the official binaries were compiled without --enable-ipv6?
--
___
Python
Change by Alex Grönholm :
--
components: +asyncio
nosy: +yselivanov
___
Python tracker
<https://bugs.python.org/issue39148>
___
___
Python-bugs-list mailin
New submission from Alex Grönholm :
Receiving a UDP datagram using DatagramProtocol on the Proactor event loop
results in error_received() being called with WinError 87 (Invalid Parameter).
The low-level sock_recv() works fine, but naturally loses the sender address
information. The attached
Alex Grönholm added the comment:
Can you reproduce this on localhost, or over Ethernet while only listening on
that specific interface? If not, then likely this is just a Wireshark artifact.
Failing that, you should construct a script that allows others to try to
reproduce the effect
Change by Alex Grönholm :
--
keywords: +patch
pull_requests: +13568
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13680
___
Python tracker
<https://bugs.python.org/issu
Alex Grönholm added the comment:
I'll look into making a PR.
--
___
Python tracker
<https://bugs.python.org/issue36999>
___
___
Python-bugs-list m
New submission from Alex Grönholm :
Both curio and trio expose the coroutine object belonging to a task as the
"coro" attribute. Asyncio exposes this as "_coro" (as does uvloop) but it would
be nice to have at least a read-only attribute exposing this as part of the
public
Change by Alex Grönholm :
--
pull_requests: +8202
___
Python tracker
<https://bugs.python.org/issue34270>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alex Grönholm added the comment:
>
I'll do that if you say so, but I'm just saying that the C and Python
implementations will still remain different in semantics then.
Never mind, that was a brain fart. I keep ignoring the &
Alex Grönholm added the comment:
> Please just change PyUnicode_Check to PyUnicode_CheckExact in C Task.__init__
> and use the same if check in C Task.set_name.
I'll do that if you say so, but I'm just saying that the C and Python
implementations will still remain different i
Alex Grönholm added the comment:
> On the other had, the matter is made moot by using PyUnicode_CheckExact()
Then, in order to keep the pure Python implementation in sync, we'd have to
change it to something like this:
if name is None:
self._name = f'Task-{_task_name_cou
Alex Grönholm added the comment:
Which way do we want to change this? Do we want to convert to pure strings or
retain the original object? In the latter case both the C and Python
implementations (including set_name()) have to be changed
Alex Grönholm added the comment:
> It's not a bad thing, it's just that we don't do it in C Task and we do it in
> pure Python Task. Eric wants us to synchronize them so that in a very
> unlikely scenario where someone uses subclasses of str for names they will
>
Alex Grönholm added the comment:
Ok, I understand. But is the conversion a bad thing then?
--
___
Python tracker
<https://bugs.python.org/issue34270>
___
___
Alex Grönholm added the comment:
Yury, I have no objections. Furthermore, it would be nice to expose the
coroutine object publicly, like curio and trio do. It would make life simpler
for me in some cases.
--
___
Python tracker
<ht
Alex Grönholm added the comment:
I also couldn't figure out yet why PyUnicode_Check() was necessary in the first
place. Doesn't PyObject_Str() just increment the refcount if the argument is
already a string?
Eric, please explain why these changes shou
New submission from Alex Grönholm :
Having names on tasks helps tremendously when something goes wrong in a complex
asyncio application. Threads have names and even trio has the ability to name
its tasks. This would also greatly benefit PyCharm's concurrency visualization:
Alex Grönholm added the comment:
Are you sure this has been fixed? The attached script reproduces the bug 100%
reliably on my laptop.
--
Added file: http://bugs.python.org/file46198/read_subprocess.py
___
Python tracker
<http://bugs.python.
Changes by Alex Grönholm :
--
nosy: +alex.gronholm
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue23242>
___
___
Python-bugs-list mailin
Alex Grönholm added the comment:
HTTP/2 (h2) is kind of a biggie :)
--
___
Python tracker
<http://bugs.python.org/issue28453>
___
___
Python-bugs-list mailin
New submission from Alex Grönholm:
the ssl.SSLObject class supports selected_alpn_protocol() like ssl.SSLSocket,
but it is not mentioned on the list of supported methods.
--
assignee: christian.heimes
components: SSL
messages: 278739
nosy: alex.gronholm, christian.heimes
priority
Alex Grönholm added the comment:
So is this going to make it into 3.6...?
--
nosy: +Alex Grönholm
___
Python tracker
<http://bugs.python.org/issue23749>
___
___
Alex Grönholm added the comment:
I wonder why they forward references are evaluated *at all* at this point.
Seems senseless to me. This should be the job of the static type checker or the
get_type_hints() function.
--
nosy: +alex.gronholm
New submission from Alex Grönholm:
>>> from typing import Union, Iterable
>>> Union[str, Iterable[int]]
typing.Iterable[int]
The union loses the "str" parameter because issubclass(str,
collections.abc.Iterable) returns True and the check completely disregards
gen
Changes by Alex Grönholm :
--
nosy: +alex.gronholm
___
Python tracker
<http://bugs.python.org/issue24900>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alex Grönholm added the comment:
I've implemented my background-calling code in my framework via
run_in_executor() now, so this has become a non-issue for me. I have no more
interest in this patch.
--
___
Python tracker
<http://bugs.py
Changes by Alex Grönholm :
--
nosy: +alex.gronholm
___
Python tracker
<http://bugs.python.org/issue23749>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alex Grönholm added the comment:
I've already made my case on python-ideas, so let's talk it over there.
--
___
Python tracker
<http://bugs.python.o
Alex Grönholm added the comment:
Where do we stand with this then? Should I start a thread on python-dev to get
the ball rolling?
--
___
Python tracker
<http://bugs.python.org/issue24
Alex Grönholm added the comment:
Why do you want to keep threads separate from asyncio? What's the downside here?
The use of helper functions is justifiable when integrating a third party
framework or similar with asyncio, but standard library components should just
integrate well with
Changes by Alex Grönholm :
--
nosy: +alex.gronholm
___
Python tracker
<http://bugs.python.org/issue24755>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alex Grönholm added the comment:
Created issue 24785 for the documentation of wrap_future().
--
___
Python tracker
<http://bugs.python.org/issue24383>
___
___
New submission from Alex Grönholm:
Since Python 3.5 will not support awaiting for concurrent.futures.Futures
natively, one has to use the asyncio.futures.wrap_future() function in
coroutines like this:
async def foo():
await wrap_future(executor.submit(...))
The wrap_future() function is
Alex Grönholm added the comment:
+1. It was specifically SQLAlchemy (but not limited to it -- there are many
other blocking APIs) that made me look for a way to easily use threads with
native coroutines.
The best workaround I've come up with:
from asyncio import wrap_future
async de
Alex Grönholm added the comment:
Updated patch per review comments.
I also corrected the order of the lines in the new block. If _must_cancel is
True, it would have tried to call cancel() on _fut_waiter before it was set.
Now the code matches that of the original block.
The docs don't
Alex Grönholm added the comment:
You're right Stefan -- I too was appalled that this was not possible in 3.5 to
begin with. It feels completely natural to be able to await for concurrent
Futures. But as this is considered a feature, it'll probably have to wait until
3.6. Otherwise
Alex Grönholm added the comment:
Ah hehe, I forgot to actually attach the patch. Thanks Yury.
The asyncio docs need to explicitly mention that concurrent.futures.Futures can
be directly awaited from coroutines. Aside from that, I think we're set -- just
need Guido to chime in on
Alex Grönholm added the comment:
I'm having trouble compiling the latest default (@859a45ca1e86). Getting linker
errors. I've updated the patch with Yury's tests in it. Would someone mind
running them? Apparently they do pass on
Alex Grönholm added the comment:
Nevermind, I was running the wrong Python version.
--
___
Python tracker
<http://bugs.python.org/issue24383>
___
___
Python-bug
Alex Grönholm added the comment:
Yury, your tests complete even without any patches on cpython default
(@74fc1af57c72). How is that possible? I verified that they are run.
--
___
Python tracker
<http://bugs.python.org/issue24
Alex Grönholm added the comment:
I agree with Stefan and Yury. As for the tests, Yury seemed to have those in
his patches -- I'll take a look and see if they're directly applicable.
For Python 3.5 and earlier, there is a workaround to awaiting for concurrent
Futures, but it requir
Alex Grönholm added the comment:
I think concurrent.futures.Future warrants adding support for in Task. It
predates asyncio and is generic enough. Can you elaborate on what other types
you would want to support as awaitables in Task?
--
___
Python
Alex Grönholm added the comment:
Sorry to keep you waiting. This sample code runs fine with the attached patch:
https://gist.github.com/agronholm/43c71be0028bb866753a
In short, I implemented support for concurrent.futures in the asyncio Task
class instead of making concurrent.futures aware of
Alex Grönholm added the comment:
Yes, Yury's approach is wrong here -- Futures should not know about asyncio,
but asyncio should be able to handle Futures natively. This seems like the
obvious solution to me. Any counterarguments?
--
nosy: +alex.gro
Alex Grönholm added the comment:
Was __await__() deliberately left out of concurrent.futures.Future or was that
an oversight? Or am I misunderstanding something?
--
nosy: +alex.gronholm
___
Python tracker
<http://bugs.python.org/issue24
Changes by Alex Grönholm :
--
nosy: +alex.gronholm
___
Python tracker
<http://bugs.python.org/issue20737>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alex Grönholm added the comment:
Python 3.3 is entering beta soon. The develop command is a must have,
especially now that virtualenv is part of the official Python distribution. Can
someone summarize what still needs to be done to get this feature merged?
--
nosy: +agronholm
New submission from Alex Grönholm :
Apparently they worked in 1.0a3 but not in 1.0a4 anymore.
--
assignee: eric.araujo
components: Distutils2
messages: 160184
nosy: agronholm, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Classifiers are missing from
Alex Grönholm added the comment:
Kubuntu 11.10, 64-bit. No ~/.pydistutils.cfg. What other info do you need?
--
___
Python tracker
<http://bugs.python.org/issue14
Alex Grönholm added the comment:
>> Ignoring site-local configuration
>What do you mean? sitecustomize is executed, for example.
Whatever, but it only looks for the paths in the included sysconfig.cfg. If the
system Python uses a different sort of path in site.py, distutils2 won
Alex Grönholm added the comment:
>If I understand correctly that you used “/usr/bin/python pysetup install spam”
>and wanted it to install to /usr/lib/python2.7/site-packages, then I think
>that the correct reply is: Not supported, don’t do that. If you did something
>else, plea
Alex Grönholm added the comment:
>I can’t reproduce. Can you delete your venv, start again and tell me how it
>goes?
I've repeated this several times, and the result is always the same.
--
___
Python tracker
<http://bugs.python.
Alex Grönholm added the comment:
>The supposed way to work, for OS packagers, is to ship this
>sysconfig.cfg thing.
Even for Pythons older than 3.3?
--
___
Python tracker
<http://bugs.python.org/i
Alex Grönholm added the comment:
Log attached.
--
Added file: http://bugs.python.org/file24927/d2log.txt
___
Python tracker
<http://bugs.python.org/issue14
Changes by Alex Grönholm :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue14357>
___
___
Python-bugs-list mailing list
Unsubscri
1 - 100 of 107 matches
Mail list logo