[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/issue46

[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 f

[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 h

[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

[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

[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

[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/issu

[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

[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.o

[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 track

[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

[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 ca

[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

[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

[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

[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

[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

[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

[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/issue46

[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/issue46

[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

[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/issue46

[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

[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:

[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

[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/issu

[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 _Type

[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/issue40

[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 <ht

[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/issu

[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 mailin

[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 <ht

[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:

[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/issu

[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

[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/issue41

[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

[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/issue40

[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.

[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/issue39

[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 b

[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 mailin

[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/issue39

[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:

[issue40213] contextlib.aclosing()

Alex Grönholm added the comment: Seconded. -- nosy: +alex.gronholm ___ Python tracker <https://bugs.python.org/issue40213> ___ ___ Python-bugs-list mailin

[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

[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 mailin

[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

[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

[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/issu

[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 mailin

[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

[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:

[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 "!&quo

[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 sem

[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()}' e

[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

[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 sa

[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> ___ ___

[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 <ht

[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

[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

[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.

[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

[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> ___ ___

[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

[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/i

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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] 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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

  1   2   >