[issue46771] Add some form of cancel scopes
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.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 > documentation for the final feature yet, but that's the impression I got from > the PEP. No, you need the new except* syntax for that. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 the handling code. Raising multiple CancelledErrors is not the only way to accomplish this. We could store the nonces in a single CancelledError instead. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 backwards incompatible changes in cancellation behavior. Previously, when the task was cancelled twice, only one CancelledError was raised. Now it would raise a BaseExceptionGroup instead. The current backward incompatible changes in cancellation behavior are already causing 10 tests to fail in the AnyIO test suite. I'm trying to find an alternate solution that does not break anything. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46805] Add low level UDP socket functions to asyncio
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 NameError about a function used by existing tests but for some reason, it's not defined in the scope of the new test functions?!? The proactor version of sock_recvfrom_into() is giving me quite a bit of trouble, as it seems to require heavy handed changes in _overlapped.c. I'm also not very successful in testing cases where sendto() would fill the kernel buffer and raise BlockingIOError. With TCP this is easy but with UDP near impossible to do in a controlled fashion in the test suite. -- ___ Python tracker <https://bugs.python.org/issue46805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 use case do you have that cannot be solved by some variation of the > "cancel count" proposal? I'm not sure I'm keeping proper track of the variations, but it seems it still relies on task uncancellation. But worse than that, (correct me if I'm wrong) it makes the innermost context manager handle the cancellation, even if it was requested by an outer one. If you have 3 nested "cancel scopes" and the task is cancelled once, how do you know which one of those context managers should handle the cancellation? I'm not sure my proposal is a fix-all either, in its current form. Sure, it fixes the case where a full task cancellation would go unnoticed, but if two unrelated context managers trigger cancellation at the same time, only the first one would actually receive it. Perhaps then we need to raise a CancelledError separately for each scope? I'm not sure yet. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46805] Add low level UDP socket functions to asyncio
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/issue46805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 to be some way to avoid a whole-task cancellation being ignored when it happens after a cancel scope triggers a cancellation for itself. My proposal solves that problem, and I think it eliminates the need for un-cancellation or other backwards incompatible changes. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46805] Add low level UDP socket functions to asyncio
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 tracker <https://bugs.python.org/issue46805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46805] Add low level UDP socket functions to asyncio
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 sock_receive() with UDP sockets but that would discard the sender address which is a showstopper problem. Also, having a send function that applies back pressure to the sender if the kernel buffer is full would also be prudent. I will provide a PR if you're okay with this. It would include the following functions: * sock_sendto() * sock_recvfrom() * sock_recvfrom_into() -- components: asyncio messages: 413579 nosy: alex.gronholm, asvetlov, yselivanov priority: normal severity: normal status: open title: Add low level UDP socket functions to asyncio type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 again, but with scope=None (the default), it clears out the saved scope, if any. Any other scope will be ignored. This simple change would allow for proper implementation of any context manager that needs to swallow or transform a CancelledError raised in the task. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 cancelled, it could still get stuck waiting on whatever the parent task happens to be waiting on, if it's not at TaskGroup.__aexit__() yet. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 way too long) -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 run to completion successfully. I was also surprised to notice that TaskGroup doesn't have a .cancel() method, so in cases where one would launch multiple tasks and cancel the rest when one succeeds, one would have to store all the child tasks separately and then iterate over them and cancel one by one. The Happy Eyeballs algorithm is one such use case (also used in AnyIO this way). -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 get back to you after that. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 awkward hacks we have now. As for async-timeout, it suffers from the same problem as AnyIO and Quattro: that cancellations of the entire task can be inadvertently swallowed by the async context manager in edge cases. I hadn't even thought of the possibility of this happening until one of AnyIO's users reported just such a problem: https://github.com/agronholm/anyio/issues/374 I just couldn't think of any way to correctly support such things without at least _some_ changes to the task cancellation behavior, and allowing .cancel() to update the cancel message seemed like the least invasive option. I'm all ears if someone has a better solution. -- nosy: -ajoino ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 cancellation, which means cancellation won't be propagated (i.e. raised in the coroutine function) from a cancelled outer scope until either the inner scope's shielding is disabled or the inner scope is exited or cancelled directly. The fundamental problem in implementing these on top of asyncio is that native task cancellation can throw a wrench in these gears. Since a cancel scope works by catching a cancellation error and then (potentially) allowing the coroutine to proceed, it would have to know, when catching a cancellation error, if the cancellation error was targeted at a cancel scope or the task itself. A workaround for this, made possible in Python 3.9, is to (ab)use cancellation messages to include the ID of the target cancel scope. This only solves half of the problem, however. If the task is already pending a cancellation targeted at a cancel scope, the task itself cannot be cancelled anymore since calling cancel() again on the task is a no-op. This would be solved by updating the cancel message on the second call. The docs don't say anything about the behavior on the second call, so it's not strictly speaking a change in documented behavior. Then, on the subject of level cancellation: level cancellation builds upon cancel scopes and changes cancellation behavior so that whenever a task yields while a cancelled cancel scope is in effect, it gets hit with a CancelledError every time, as opposed to just once in asyncio's "edge" style cancellation. Another very important difference is that with level cancellation, even a task that starts within a cancelled scope gets to run up until the first yield point. This gives it an opportunity to clean up any resources it was given ownership of (a connected socket in a socket server is a common, practical example of this). This is what the asyncio documentation states about Task.cancel(): "This arranges for a CancelledError exception to be thrown into the wrapped coroutine on the next cycle of the event loop. The coroutine then has a chance to clean up or even deny the request by suppressing the exception with a try … … except CancelledError … finally block. Therefore, unlike Future.cancel(), Task.cancel() does not guarantee that the Task will be cancelled, although suppressing cancellation completely is not common and is actively discouraged." This is, however, only true for a task that has started running. A Task that gets cancelled before even entering the coroutine is silently dropped. As asyncio does not allow for custom task instances without overriding the entire task factory, it leaves libraries like AnyIO some less desirable options for implementing level cancellation: 1. Implementing a parallel task system using low level synchronous callbacks (con: such tasks won't show up in asyncio.all_tasks() or work with third party debugging tools) 2. Adding callbacks to continuously cancel tasks that yield inside a cancelled scope (con: ugly; potentially extra overhead?) 3. Adding a wrapper for the task that acts as a "controller" (con: adds an extra visible stack frame, messes with the default task name) Having low level machinery for injecting a custom Task instance to the event loop would probably solve this problem. -- nosy: +alex.gronholm -tinchester ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3
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/issue46313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3
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/issue46313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3
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 tracker <https://bugs.python.org/issue46313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3
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/issue46313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46313] SSLObject does not raise SSLEOFError on OpenSSL 3
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 explicitly unsetting the SSL_OP_IGNORE_UNEXPECTED_EOF flag and then checking if the "strerror" attribute of SSLError contains the text "UNEXPECTED_EOF_WHILE_READING". The remedy in the standard library would be twofold: 1. Revert the change of enabling SSL_OP_IGNORE_UNEXPECTED_EOF by default 2. Handle the condition properly so that SSLEOFError is raised instead of the generic SSLError As SSLSockets ignore SSLEOFError by default, this fix should work fine for those too. -- assignee: christian.heimes components: SSL messages: 410146 nosy: alex.gronholm, christian.heimes, lukasz.langa priority: normal severity: normal status: open title: SSLObject does not raise SSLEOFError on OpenSSL 3 type: security versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Change by Alex Grönholm : -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43794] OpenSSL 3.0.0: Handle UNEXPECTED_EOF_WHILE_READING / wrap SSL_OP_IGNORE_UNEXPECTED_EOF
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 in such a way that previously detectable unexpected EOFs are now no longer detectable by default. To make matters worse, EOF errors are not translated to SSLEOFError anymore, and instead I have to match the strerror attribute in SSLError to detect this condition. -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue43794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42059] TypedDict(...) as function does not respect "total" when setting __required_keys__ and __optional_keys__
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/issue42059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42059] TypedDict(...) as function does not respect "total" when setting __required_keys__ and __optional_keys__
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 the "total" metaclass
argument to _TypedDictMeta() (instead passing "__total__" in the attribute
namespace) and the new code that sets __required_keys__ and __optional_keys__
only checks the metaclass argument.
--
components: Library (Lib)
messages: 378805
nosy: alex.gronholm
priority: normal
severity: normal
status: open
title: TypedDict(...) as function does not respect "total" when setting
__required_keys__ and __optional_keys__
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42059>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40072] Win7/Python3.8/asyncio IPv6 UDP Server raise OSError when recved any packet
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/issue40072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40072] Win7/Python3.8/asyncio IPv6 UDP Server raise OSError when recved any packet
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 <https://bugs.python.org/issue40072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41317] sock_accept() does not remove server socket reader on cancellation
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/issue41317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41317] sock_accept() does not remove server socket reader on cancellation
Alex Grönholm added the comment: Looks like they do – fantastic! -- ___ Python tracker <https://bugs.python.org/issue41317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41317] sock_accept() does not remove server socket reader on cancellation
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 <https://bugs.python.org/issue41317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31821] pause_reading() doesn't work from connection_made()
Change by Alex Grönholm : -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue31821> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41332] connect_accepted_socket() missing from AbstractEventLoop
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/issue41332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41332] connect_accepted_socket() missing from AbstractEventLoop
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 priority: normal severity: normal status: open title: connect_accepted_socket() missing from AbstractEventLoop type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41317] sock_accept() does not remove server socket reader on cancellation
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/issue41317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41317] sock_accept() does not remove server socket reader on cancellation
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 removed. If then the server socket is closed and a new socket is created which has the same file number and it is used for a socket operation, it will cause a FileNotFoundError because the event loop thinks it has this fd registered but the epoll object does not agree since all closed sockets are automatically removed from it. The attached script reproduces the problem on Fedora Linux 32 (all relevant Python versions), but not on Windows (on any tested Python versions from 3.6 to 3.8). -- components: asyncio files: bug.py messages: 373777 nosy: alex.gronholm, asvetlov, yselivanov priority: normal severity: normal status: open title: sock_accept() does not remove server socket reader on cancellation type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file49319/bug.py ___ Python tracker <https://bugs.python.org/issue41317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40213] contextlib.aclosing()
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/issue40213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40213] contextlib.aclosing()
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.org/issue40213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
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/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
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's such a big problem. -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue35829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
Alex Grönholm added the comment: Thanks, looks good to me now! -- ___ Python tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
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.org/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
Alex Grönholm added the comment: Which PR is it? -- ___ Python tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40213] contextlib.aclosing()
Alex Grönholm added the comment: Seconded. -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue40213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
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 tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
Change by Alex Grönholm : -- components: +asyncio nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
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 script works fine as-is on Linux, and on Windows if ::1 is replaced with 127.0.0.1. There were extensive tests added for UDP support on IOCP, but unfortunately all of them use only IPv4 sockets so they could not catch this problem. -- components: Windows files: udpreceive.py messages: 358940 nosy: alex.gronholm, asvetlov, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: DatagramProtocol + IPv6 does not work with ProactorEventLoop type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48805/udpreceive.py ___ Python tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37542] UDP sendto() sends duplicate packets
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. -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue37542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36999] Expose the coroutine object in asyncio task objects
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/issue36999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36999] Expose the coroutine object in asyncio task objects
Alex Grönholm added the comment: I'll look into making a PR. -- ___ Python tracker <https://bugs.python.org/issue36999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36999] Expose the coroutine object in asyncio task objects
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 API. In some of my libraries I need this object, sometimes for debugging and other times for implementing "crazy" schemes like running parts of the the coroutine function code in a worker thread. -- components: asyncio messages: 343092 nosy: alex.gronholm, asvetlov, yselivanov priority: normal severity: normal status: open title: Expose the coroutine object in asyncio task objects type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
Change by Alex Grönholm : -- pull_requests: +8202 ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
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 "!" in my mind. -- ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
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 in semantics then. -- ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
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_counter()}'
elif isinstance(name, str):
self._name = name
else:
self._name = str(name)
I don't know about you, but it looks pretty awkward to me.
--
resolution: fixed ->
___
Python tracker
<https://bugs.python.org/issue34270>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
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. -- ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
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 > have exact same behaviour under both Tasks implementations. Should a new issue be created for this so I can make a PR against it? -- ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
Alex Grönholm added the comment: Ok, I understand. But is the conversion a bad thing then? -- ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
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 <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
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 should be done. -- ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34270] Add names to asyncio tasks
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: https://www.jetbrains.com/help/pycharm/thread-concurrency-visualization.html#asyncio -- components: asyncio messages: 322620 nosy: alex.gronholm, asvetlov, yselivanov priority: normal severity: normal status: open title: Add names to asyncio tasks type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23242] asyncio: Process must close the transport when the process exit
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 <rep...@bugs.python.org> <http://bugs.python.org/issue23242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23242] asyncio: Process must close the transport when the process exit
Changes by Alex Grönholm <alex.gronholm+pyt...@nextday.fi>: -- nosy: +alex.gronholm versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28453] SSLObject.selected_alpn_protocol() not documented
Alex Grönholm added the comment: HTTP/2 (h2) is kind of a biggie :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28453] SSLObject.selected_alpn_protocol() not documented
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: normal severity: normal status: open title: SSLObject.selected_alpn_protocol() not documented versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket (starttls)
Alex Grönholm added the comment: So is this going to make it into 3.6...? -- nosy: +Alex Grönholm ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26477] typing forward references and module attributes
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 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26075] typing.Union unifies types too broadly
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 generics. Guido mentioned that issubclass() support for generic types should be going away. In the mean time, maybe the subclass check in typing.GenericMeta should be modified not to do it with types from Typing, but how can we accurately identify them? -- components: Extension Modules messages: 257910 nosy: alex.gronholm, gvanrossum, lukasz.langa priority: normal severity: normal status: open title: typing.Union unifies types too broadly type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24900] Raising an exception that cannot be unpickled causes hang in ProcessPoolExecutor
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- nosy: +alex.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24900 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket (starttls)
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- nosy: +alex.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
Alex Grönholm added the comment: I've already made my case on python-ideas, so let's talk it over there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 each other. Requiring boilerplate wrappers for such use seems unreasonable to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24755] asyncio.wrap_future undocumented
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- nosy: +alex.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24755 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 3.5b3 at least. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
Alex Grönholm added the comment: Nevermind, I was running the wrong Python version. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 you'll end up your app requiring a specific micro-release which is a big no-no in the Python world, as far as features go at least. But if this is considered a bugfix, it could still go into 3.5.0... *wink wink*. That's what I'm hoping for of course. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 seem to explicitly say anywhere that they only accept asyncio's Futures and not concurrent Futures, so I'm unsure if any changes are needed there at all. -- Added file: http://bugs.python.org/file40106/concurrent.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 requires the use of the undocumented wrap_future() function. It is the fact that it's undocumented that bothers me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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 asyncio. The __await__ implementation in concurrent.futures closely mirrors that of asyncio's Future. -- Added file: http://bugs.python.org/file40090/asyncio_await.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
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.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
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 rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20737] 3.3 _thread lock.acquire() timeout and threading.Event().wait() do not wake for certain values on Windows
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- nosy: +alex.gronholm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20737 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8668] Packaging: add a 'develop' command
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8668 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14747] Classifiers are missing from distutils2-generated metadata
New submission from Alex Grönholm alex.gronholm+pyt...@nextday.fi: 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 distutils2-generated metadata type: behavior versions: 3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14747 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14357] Distutils2 does not work with virtualenv
Alex Grönholm alex.gronholm+pyt...@nextday.fi added the comment: Kubuntu 11.10, 64-bit. No ~/.pydistutils.cfg. What other info do you need? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14357 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14356] Distutils2 ignores site-local configuration
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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't use it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14356] Distutils2 ignores site-local configuration
New submission from Alex Grönholm alex.gronholm+pyt...@nextday.fi: Distutils2 seems to rely solely on a sysconfig.cfg shipped with distutils2 to get the path where to install packages. Ignoring site-local configuration means that it won't work on Python distributions where the site configuration has been customized. On Ubuntu, packages are supposed to go to /usr/local/lib/python2.7/dist-packages but distutils2 tries to install them to /usr/lib/python2.7/site-packages. -- assignee: eric.araujo components: Distutils2 messages: 156230 nosy: agronholm, alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Distutils2 ignores site-local configuration type: behavior versions: 3rd party, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14357] Distutils2 does not work with virtualenv
New submission from Alex Grönholm alex.gronholm+pyt...@nextday.fi: The installed pysetup script launches (at least on my system) with /usr/bin/python regardless of the interpreter used for installing it. -- assignee: eric.araujo components: Distutils2 messages: 156231 nosy: agronholm, alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Distutils2 does not work with virtualenv versions: 3rd party, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14357 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14357] Distutils2 does not work with virtualenv
Changes by Alex Grönholm alex.gronholm+pyt...@nextday.fi: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14357 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14357] Distutils2 does not work with virtualenv
Alex Grönholm alex.gronholm+pyt...@nextday.fi added the comment: Log attached. -- Added file: http://bugs.python.org/file24927/d2log.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14357 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14356] Distutils2 ignores site-local configuration
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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 rep...@bugs.python.org http://bugs.python.org/issue14356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14357] Distutils2 does not work with virtualenv
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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 rep...@bugs.python.org http://bugs.python.org/issue14357 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14356] Distutils2 ignores site-local configuration
Alex Grönholm alex.gronholm+pyt...@nextday.fi 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, please tell what it was :) Did something along the lines of pysetup install sqlalchemy and it's trying to install it under /usr/lib/python2.7/site-packages, which is of course wrong. But since it ignores the customized site-local configuration, how could it possibly know where to install? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14356 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14352] Distutils2 won't install on Ubuntu
New submission from Alex Grönholm alex.gronholm+pyt...@nextday.fi: Running distutils2 hg tip (changeset 2cec52b682a9): The command pysetup install fails with: u'Python': u'2.7.2+' is not a valid version (field 'Version') Not that it should matter, but this is Ubuntu 11.10. Also, distutils2 installs fine using setup.py. -- assignee: eric.araujo components: Distutils2 files: d2log.txt messages: 156196 nosy: agronholm, alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Distutils2 won't install on Ubuntu type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file24914/d2log.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14352 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
