[issue40840] lzma.h file not found building on macOS

2020-11-26 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Yes. If I trust my message from earlier, this issue is resolved. Closing now.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue42405] Add distutils mvsccompiler support for Windows ARM64 build

2020-11-22 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

As I reviewed the PR, I do realize how tricky this change is going to be. In 
addition to the three MSVC implementations in distutils, Setuptools has its own 
(https://github.com/pypa/setuptools/blob/master/setuptools/msvc.py).

Interestingly, that file indicates support for ARM (when describing support for 
MSVC 14+), so at least someone has previously embarked on this territory.

If it turns out that supporting ARM in msvc9compiler also implies adding 
support for MSVC 14+, I think you'll be hard-pressed to find a satisfying 
solution that doesn't break compatibility for many use-cases.

Thanks for investigating this issue and good luck.

--

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



[issue42405] Add distutils mvsccompiler support for Windows ARM64 build

2020-11-20 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

If you wish for the functionality to be available in setuptools (backported), 
please contribute the change at https://github.com/pypa/distutils. At some 
point, contributions to CPython will also be synced there as well, and any 
changes there get synced into Setuptools. Unfortunately, at this stage, that 
functionality is only exposed through a feature flag when 
`SETUPTOOLS_USE_DISTUTILS=local` is set... until downstream implementations in 
Linux distributions and monkeypatches such as with Numpy can be updated not to 
rely on the implementation details as found in the stdlib.

--

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



[issue42382] No easy way to get the distribution which provided a importlib.metadata.EntryPoint

2020-11-17 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Yes - I keep both in sync.

--

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



[issue42382] No easy way to get the distribution which provided a importlib.metadata.EntryPoint

2020-11-17 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Pedro - thanks for the detailed report. Pull requests against 
importlib_metadata are easier to accept because they can be tested more easily, 
released more rapidly, and there's a straightforward way to port them to 
CPython. Regardless, I see you've proposed a change to CPython, so I can work 
with that.

--

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



[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

2020-11-04 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I marked bpo-42263 as a duplicate of this issue.

This issue is implicated in preventing the desired fix for bpo-37193, where a 
thread wishes to remove the handle to itself after performing its duty. By 
removing its own handle, it can never be joined, and thus obviates the most 
straightforward way to directly remove the handle for a thread within that 
thread.

--
nosy: +jaraco

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



[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

2020-11-04 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
versions: +Python 3.10

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



[issue42263] Removing thread reference in thread results in leaked reference

2020-11-04 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Yes, I agree it's a duplicate of issue37788. 

And yes, it does still leak if the list is never created or if the target is a 
no-op.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> fix for bpo-36402 (threading._shutdown() race condition) causes 
reference leak

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



[issue42263] Removing thread reference in thread results in leaked reference

2020-11-04 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I don't think it's a race condition for two reasons: adding a `time.sleep(1)` 
after `.start` still raises errors, and in issue37193, there were 10 threads 
created, with at least 9 of those reaching termination before the test ended, 
yet it showed 10 reference leaks.

If you join the thread in the test, the leak is not detected. However, I 
believe that's because, in order to join on the thread, you must also hold a 
handle to the thread, so the condition isn't triggered.

--

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



[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

2020-11-04 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I filed issue42263 to capture the underlying cause of the memory leak that led 
to the buildbot failures and the rollback.

--

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



[issue42263] Removing thread reference in thread results in leaked reference

2020-11-04 Thread Jason R. Coombs


New submission from Jason R. Coombs :

In issue37193, I'd worked on an implementation in which a thread reference 
would be removed as the thread was closing, but this led to a memory leak 
caught by the buildbots (https://bugs.python.org/issue37193#msg380172).

As I tracked down the issue in GH-23127, I discovered that removing the 
reference to the thread from within the thread triggered the reference leak 
detection.

I've distilled that behavior into its own test which fails on master:

```
cpython master $ git diff
diff --git a/Lib/test/test_threading.py b/Lib/test/test_threading.py
index e0e5406ac2..2b4924d4d0 100644
--- a/Lib/test/test_threading.py
+++ b/Lib/test/test_threading.py
@@ -443,6 +443,15 @@ def _run(self, other_ref, yet_another):
  msg=('%d references still around' %
   sys.getrefcount(weak_raising_cyclic_object(
 
+def test_remove_thread_ref_in_thread(self):
+def remove_ref():
+threads[:] = []
+
+threads = [
+threading.Thread(target=remove_ref),
+]
+threads[0].start()
+
 def test_old_threading_api(self):
 # Just a quick sanity check to make sure the old method names are
 # still present
```

Running that test with refcount checks leads to this failure:

```
cpython master $ ./python.exe Tools/scripts/run_tests.py -R 3:3 
test.test_threading -m test_remove_thread_ref_in_thread
/Users/jaraco/code/public/cpython/python.exe -u -W default -bb -E -m test -r -w 
-j 0 -u all,-largefile,-audio,-gui -R 3:3 test.test_threading -m 
test_remove_thread_ref_in_thread
Using random seed 8650903
0:00:00 load avg: 1.76 Run tests in parallel using 10 child processes
0:00:01 load avg: 1.78 [1/1/1] test.test_threading failed

== Tests result: FAILURE ==

1 test failed:
test.test_threading
0:00:01 load avg: 1.78
0:00:01 load avg: 1.78 Re-running failed tests in verbose mode
0:00:01 load avg: 1.78 Re-running test.test_threading in verbose mode
beginning 6 repetitions
123456
..
test.test_threading leaked [1, 1, 1] references, sum=3
test.test_threading leaked [3, 1, 1] memory blocks, sum=5
beginning 6 repetitions
123456
test_remove_thread_ref_in_thread (test.test_threading.ThreadTests) ... ok

--

Ran 1 test in 0.001s

OK
.test_remove_thread_ref_in_thread (test.test_threading.ThreadTests) ... ok

--

Ran 1 test in 0.001s

OK
.test_remove_thread_ref_in_thread (test.test_threading.ThreadTests) ... ok

--

Ran 1 test in 0.001s

OK
.test_remove_thread_ref_in_thread (test.test_threading.ThreadTests) ... ok

--

Ran 1 test in 0.001s

OK
.test_remove_thread_ref_in_thread (test.test_threading.ThreadTests) ... ok

--

Ran 1 test in 0.001s

OK
.test_remove_thread_ref_in_thread (test.test_threading.ThreadTests) ... ok

--

Ran 1 test in 0.001s

OK
.
test.test_threading leaked [1, 1, 1] references, sum=3
test.test_threading leaked [1, 1, 1] memory blocks, sum=3
1 test failed again:
test.test_threading

== Tests result: FAILURE then FAILURE ==

1 test failed:
test.test_threading

1 re-run test:
test.test_threading

Total duration: 2.0 sec
Tests result: FAILURE then FAILURE
```

Is that behavior by design? Is it simply not possible to remove a reference to 
a thread from within the thread?

--
messages: 380353
nosy: jaraco
priority: normal
severity: normal
status: open
title: Removing thread reference in thread results in leaked reference
versions: Python 3.10

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



[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

2020-11-03 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +22043
pull_request: https://github.com/python/cpython/pull/23127

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



[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

2020-11-02 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +22024
pull_request: https://github.com/python/cpython/pull/23107

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



[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

2020-11-02 Thread Jason R. Coombs

Jason R. Coombs  added the comment:

I recommend a rollback. I’ll try to get to it later today.

--

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



[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

2020-11-01 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset c41559021213cfc9dc62a83fc63306b3bdc3e64b by MARUYAMA Norihiro in 
branch 'master':
bpo-37193: remove thread objects which finished process its request (GH-13893)
https://github.com/python/cpython/commit/c41559021213cfc9dc62a83fc63306b3bdc3e64b


--

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



[issue42163] _replace() no longer works on platform.uname_result objects

2020-10-29 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Please take a look at the PR. Let me know what you think about the limited 
compatibility it adds (still doesn't allow _replace on 'processor').

--

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



[issue42189] copy.deepcopy() no longer works on platform.uname_result objects

2020-10-29 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
keywords: +patch
pull_requests: +21945
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23010

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



[issue42189] copy.deepcopy() no longer works on platform.uname_result objects

2020-10-29 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Acknowledged. Thanks for the report. I'll likely address this issue alongside 
the other (same PR).

--
assignee:  -> jaraco

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



[issue42163] _replace() no longer works on platform.uname_result objects

2020-10-27 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
keywords: +patch
pull_requests: +21926
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23010

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



[issue42163] _replace() no longer works on platform.uname_result objects

2020-10-27 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Indeed, it was unexpected that consumers of the `uname_result` were using 
`_replace`. In fact, the focus of the tests is on ensuring that users are able 
to access the items by index, e.g. `uname()[0]`.

It should be possible to support `_replace` on the `uname_result` as found in 
Python 3.9+. The real question is - is it important enough to declare and 
restore support for this use case based on this one report (and likely handful 
of other cases), or would it be better to discourage use of `_replace` for 
`uname_result` and provide a straightforward workaround (to be documented here) 
for those use-cases to employ?

Marc, do you have an opinion?

--
nosy: +lemburg -rhettinger
versions: +Python 3.10

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



[issue42163] _replace() no longer works on platform.uname_result objects

2020-10-27 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
assignee:  -> jaraco

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



[issue42090] zipfile.Path.joinpath API inconsistent with pathlib.Path.joinpath

2020-10-25 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
stage: patch review -> commit review

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



[issue42090] zipfile.Path.joinpath API inconsistent with pathlib.Path.joinpath

2020-10-25 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
keywords: +patch
pull_requests: +21893
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/22976

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



[issue42043] zipfile.Path should support inheritance

2020-10-25 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset d1a0a960ee493262fb95a0f5b795b5b6d75cecb8 by Jason R. Coombs in 
branch 'master':
bpo-42043: Add support for zipfile.Path subclasses (#22716)
https://github.com/python/cpython/commit/d1a0a960ee493262fb95a0f5b795b5b6d75cecb8


--

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



[issue42090] zipfile.Path.joinpath API inconsistent with pathlib.Path.joinpath

2020-10-25 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

This issue is fixed in zipp 3.4.0.

--
assignee:  -> jaraco
stage:  -> backport needed

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



[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

2020-10-25 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset df8d4c83a6e1727e766191896aeabde886979587 by Jason R. Coombs in 
branch 'master':
bpo-41490: ``path`` and ``contents`` to aggressively close handles (#22915)
https://github.com/python/cpython/commit/df8d4c83a6e1727e766191896aeabde886979587


--

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



[issue42129] Support resources in namespace packages

2020-10-23 Thread Jason R. Coombs


New submission from Jason R. Coombs :

In 
[importlib_resources#68](https://github.com/python/importlib_resources/issues/68),
 the project identified a deficiency with respect to pkg_resources for 
resources in namespace packages.

The project has since merged support for these packages, slated to go out with 
the importlib_resources 3.2 release.

This issue is to track the incorporation of those changes into 
importlib.resources.

--
assignee: jaraco
messages: 379451
nosy: jaraco
priority: normal
severity: normal
status: open
title: Support resources in namespace packages
versions: Python 3.10

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



[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

2020-10-23 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +21845
pull_request: https://github.com/python/cpython/pull/22915

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



[issue42089] Better message in PackageNotFoundError

2020-10-20 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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



[issue42090] zipfile.Path.joinpath API inconsistent with pathlib.Path.joinpath

2020-10-20 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

This sounds like a worthy improvement. Are you interested in preparing a patch? 
Would you consider contributing it to https://github.com/jaraco/zipp first?

--

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



[issue42089] Better message in PackageNotFoundError

2020-10-19 Thread Jason R. Coombs


New submission from Jason R. Coombs :

As reported in https://gitlab.com/python-devs/importlib_metadata/-/issues/124, 
it would be nice if the PackageNotFoundError gave some guidance to the user 
about the context of the error and how to investigate.

--
assignee: jaraco
components: Library (Lib)
messages: 379015
nosy: jaraco
priority: normal
severity: normal
status: open
title: Better message in PackageNotFoundError
versions: Python 3.10

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



[issue42043] zipfile.Path should support inheritance

2020-10-15 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +21684
pull_request: https://github.com/python/cpython/pull/22716

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



[issue41855] FastPath.zip_children can give duplicate results on Python 3.8

2020-10-15 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset 967fddae2fe48f297563c358bdbdde1e2cfed4ee by Jason R. Coombs in 
branch '3.8':
[3.8] bpo-41855: Fix duplicate results in FastPath.zip_children() (#22404)
https://github.com/python/cpython/commit/967fddae2fe48f297563c358bdbdde1e2cfed4ee


--

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



[issue42043] zipfile.Path should support inheritance

2020-10-15 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

This issue was addressed incidentally in 
[jaraco/zipp#56](https://github.com/jaraco/zipp/issues/56) released as zipp 
3.2.0.

I'd like to incorporate the tests submitted in PR 22711 and then port those 
changes to Python.

--

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



[issue21927] BOM appears in stdin when using Powershell

2020-10-12 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Thanks Eryk for following up. Glad to hear the issue has been fixed upstream!

--

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-10-03 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
resolution:  -> fixed

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-10-03 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Fix merged into master. Please use zipp 3.2.0 on Python 3.9 and earlier for the 
improved behavior or report back here if a backport is needed (and why).

--
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.8

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-10-03 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset ebbe8033b1c61854c4b623aaf9c3e170d179f875 by Jason R. Coombs in 
branch 'master':
bpo-40564: Avoid copying state from extant ZipFile. (GH-22371)
https://github.com/python/cpython/commit/ebbe8033b1c61854c4b623aaf9c3e170d179f875


--

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



[issue41855] FastPath.zip_children can give duplicate results on Python 3.8

2020-09-24 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +21444
pull_request: https://github.com/python/cpython/pull/22404

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



[issue41855] FastPath.zip_children can give duplicate results on Python 3.8

2020-09-24 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
keywords: +patch
pull_requests: +21443
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22403

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



[issue41855] FastPath.zip_children can give duplicate results on Python 3.8

2020-09-24 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

The relevant commit is already present in importlib_metadata as 
[079ca1cb701a5f4aab0a9cb00b0782c7ea8fb70b](https://gitlab.com/python-devs/importlib_metadata/-/commit/079ca1cb701a5f4aab0a9cb00b0782c7ea8fb70b).

--
components: +Library (Lib)

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



[issue41855] FastPath.zip_children can give duplicate results on Python 3.8

2020-09-24 Thread Jason R. Coombs


New submission from Jason R. Coombs :

Scott J. reports in an e-mail:

When upgrading to Python 3.8.2, we noticed two issues in
importlib.metadata which are not present in importlib_metadata.

1.  FastPath.zip_children() is very slow for large zips. Python 3.8.3
> already has a fix for this
> 
([[bug]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.python.org%2Fissue39667=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462361570=Msk47lScorCQpx5PHiKrpeYYzBLMR89HNZ7RwY7ch4c%3D=0),
> 
[[changelog]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.python.org%2F3%2Fwhatsnew%2Fchangelog.html%23id45=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462371564=CSPBVi5rPFSCovRZdd8WNbOQ4mxDycy%2FmjDhbty4OLk%3D=0)),
> which includes merging in importlib_metadata 1.5.0.

2.  FastPath.zip_children() can give duplicate results, causing
> duplicate results in entry_points(). This issue was reported in
> importlib_metadata in March
> 
([[link]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fpython-devs%2Fimportlib_metadata%2F-%2Fissues%2F117=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462371564=g5N0ew3WAOUfPJ5eL7oY0j9NIpXkh8HAkV%2FWD4UppX8%3D=0))
> and fixed in importlib_metadata 1.5.2
> 
([[changelog]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimportlib-metadata.readthedocs.io%2Fen%2Flatest%2Fchangelog.html%23v1-5-2=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462381558=UpnqBoyl%2FcGMkF%2BfFufredA0QGt31o5Qag3joQ%2FJhDs%3D=0)).

In June, importlib_metadata 1.6.1 (including the fix for \#2) was merged
into Python
([[bug]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.python.org%2Fissue39791%23msg370782=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462381558=i8Y8o5f3uBXPP8OU9I3PkKSHzS%2B3z4kcd%2FdH1l%2B9YI8%3D=0),
[[PR]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F20659=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462391552=Q5P3RuTNpctc4E93l2dqXRc1LYmw9XSnBb%2FaJbKTcMg%3D=0))
and backported to 3.9
([[PR]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F20661=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462391552=f%2BghmbplIsbmc9CFgoQX7vxc%2FZPLG2TkEgjMZtez71s%3D=0)).
However, the backport for Python 3.8 was **not** merged
([[PR]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F20662=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462391552=JTpQpeuzE%2BGvL%2FNccWcuu0vQWRKQbkBHLmzeNmWZMFc%3D=0)).
Jason said:

> Of course this can\'t backport to 3.8; importlib.resources.files
> doesn\'t exist there. No problem. Bug fixes will need to be backported
> specially if needed.

As far as I can tell, no version of importlib_metadata newer than 1.5.0
has ever been merged into Python 3.8, and so bug \#2 is still present
(tested in 3.8.6rc1). This seems like it falls under the \"bug fixes if
needed\" category. We just need to fix the duplicate entries, as
reported in importlib_metadata. This should be trivial. The diff in
python 3.9 is
[[here]{.ul}](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F20661%2Ffiles%23diff-499abe3a411df5cf55659b640ac3b2b4L411-R435=02%7C01%7Cbwarsaw%40linkedin.com%7C514c7c4d1eea417ed26908d86024cd43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637365058462401547=qZXa9e13SVng5tkL3Im2s1Gc2OSLOKlqiiDKBTqkxoI%3D=0).

--
assignee: jaraco
messages: 377461
nosy: barry, jaraco
priority: normal
severity: normal
status: open
title: FastPath.zip_children can give duplicate results on Python 3.8
type: behavior
versions: Python 3.8

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-09-23 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I've released zipp 3.2.0 that includes a fix for this issue (option 2). Please 
test it out.

Because this change affects the user's expectation about the effect of what's 
passed in, I'm hesitant to backport it to 3.8 and 3.9. It's too late to go into 
3.9.0, so the earliest it can appear is in 3.9.1.

Please advise - does the undesirable behavior warrant a bugfix backport, or is 
it sufficient to direct users impacted by this issue prior to Python 3.10 to 
use the `zipp` backport?

--

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-09-22 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
keywords: +patch
pull_requests: +21408
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22371

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-09-22 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I've also created this alternative to option 2:

- https://github.com/jaraco/zipp/tree/bugfix/bpo-40564-mixin

This alternative approach uses a mix-in rather than subclasses, creating a new 
class on-demand. I was hoping this approach would enable just augmenting the 
instance rather than affecting `source.__class__`, but when I got to the 
implementation, I found that `source.__class__` had to be mutated regardless.

This approach does have an advantage over option 2 in that it would support 
other ZipFile subclasses for source. It has the disadvantage in that it creates 
a new subclass for every instance created.

I've thought about it a lot and while I'm not particularly happy with any of 
the approaches, I'm leaning toward option 2.

--

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



[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

2020-09-11 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

> I haven't yet figured out whether there's a convenient way for the reader to 
> not keep the ZIP open for as long as it exists, but I think that's going to 
> be the safest fix.

You may be right here. I don't fully understand the repro, but it seems to me 
like you're trying to delete a zip file while you have resources open in that 
zip file. I think we need a separate issue to capture the underlying defect.

--

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-09-09 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

In jaraco/zipp, I've implemented three of the options above:

- https://github.com/jaraco/zipp/tree/bugfix/bpo-40564-option-1
- https://github.com/jaraco/zipp/tree/bugfix/bpo-40564-option-2
- https://github.com/jaraco/zipp/tree/bugfix/bpo-40564-option-5

--

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



[issue30926] KeyError with cgitb inspecting exception in generator expression

2020-09-01 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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



[issue41615] sys.argv may be None or an empty list

2020-08-30 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

One possible option to guarantee initialization could be for PyInitialize to 
always call PySys_SetArgvEx(1, [""], 0), providing a default value for embedded 
interpreters that fail to call it.

--

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



[issue41615] sys.argv may be None or an empty list

2020-08-29 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Thanks Terry.

The correct URL is 
[jaraco/keyring#445](https://github.com/jaraco/keyring/issues/445).

--

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-08-26 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Implementing that last option:

```
diff --git a/zipp.py b/zipp.py
index 697d4a9..f244cba 100644
--- a/zipp.py
+++ b/zipp.py
@@ -111,6 +111,7 @@ class CompleteDirs(zipfile.ZipFile):
 
 res = cls.__new__(cls)
 vars(res).update(vars(source))
+res.close = lambda: None
 return res
 
 
```

Does appear to address the issue. I'm not super happy about the implementation, 
though.

--

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-08-26 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I see a few options here:

- Implement CompleteDirs/FastLookup as adapters instead of subclasses, allowing 
the original ZipFile object to represent the state in a single place. This 
approach would likely be slower due to the indirection on all operations 
through the wrapper.
- Instead of constructing a new object and copying the state, CompleteDirs.make 
could mutate the existing ZipFile class, replacing `source.__class__` with the 
new class. This approach is messy and the caller would still need to be aware 
that this change could be applied to the zipfile object.
- Consider this use-case unsupported and document that any ZipFile object 
passed into Path is no longer viable and should not be referenced for another 
purpose.
- Eliminate the class-based performance optimizations and replace them with 
some functional/imperative form. This approach may provide less separation of 
concerns.
- Disable the close-on-delete behavior for the subclasses when state is copied 
from another.

--

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-08-26 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I suspect the issue lies in how the CompleteDirs.make [replaces one instance 
with 
another](https://github.com/jaraco/zipp/blob/8ad959e61cd4be40baab93528775c2bf03c8f4e1/zipp.py#L112-L114)
 in order to provide a complete list of implied directories and to memoize the 
names lookup.

Because constructing a zipfile.Path object around a zipfile.ZipFile copies the 
underlying state, closing one will have the affect of closing the other.

I believe this issue is the same root issue as issue41350.

--

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-08-26 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I am able to replicate the failure using the ondisk fixture:

```diff
diff --git a/test_zipp.py b/test_zipp.py
index a6fbf39..539d0a9 100644
--- a/test_zipp.py
+++ b/test_zipp.py
@@ -259,3 +259,11 @@ class TestPath(unittest.TestCase):
 def test_implied_dirs_performance(self):
 data = ['/'.join(string.ascii_lowercase + str(n)) for n in 
range(1)]
 zipp.CompleteDirs._implied_dirs(data)
+
+def test_read_does_not_close(self):
+for alpharep in self.zipfile_ondisk():
+with zipfile.ZipFile(alpharep) as file:
+for rep in range(2):
+p_ = zipp.Path(file, 'a.txt')
+with p_.open() as inner:
+print(list(inner))
```

--

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



[issue40564] Using zipfile.Path with several files prematurely closes zip

2020-08-26 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I've attempted to replicate the issue in the 
[zipp](https://github.com/jaraco/zipp) test suite with this test:

```diff
diff --git a/test_zipp.py b/test_zipp.py
index a6fbf39..dc7c8aa 100644
--- a/test_zipp.py
+++ b/test_zipp.py
@@ -259,3 +259,10 @@ class TestPath(unittest.TestCase):
 def test_implied_dirs_performance(self):
 data = ['/'.join(string.ascii_lowercase + str(n)) for n in 
range(1)]
 zipp.CompleteDirs._implied_dirs(data)
+
+def test_read_does_not_close(self):
+for alpharep in self.zipfile_alpharep():
+for rep in range(2):
+p_ = zipp.Path(alpharep, 'a.txt')
+with p_.open() as inner:
+print(list(inner))
```

But the test passes.

--

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



[issue41615] sys.argv may be None or an empty list

2020-08-22 Thread Jason R. Coombs


New submission from Jason R. Coombs :

In [pypa/keyring#445](https://github.com/pypa/keyring/445) and issue839151, we 
learned that there are Python interpreters in which `sys.argv` is an empty 
list, is not a list, or is not initialized at all. Through use of 
`sys.argv[0]`, the documentation strongly implies that `sys.argv` is always a 
list of at least one element. The documentation makes no mention of these other 
cases. It would be nice if the documentation would describe what values (or 
absence thereof) are valid for `sys.argv`.

--
assignee: docs@python
components: Documentation
messages: 375796
nosy: docs@python, jaraco
priority: normal
severity: normal
status: open
title: sys.argv may be None or an empty list

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



[issue41509] ntpath.relpath behaves differently on Windows with trailing spaces

2020-08-08 Thread Jason R. Coombs


New submission from Jason R. Coombs :

On Windows:

Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:37:02) [MSC v.1924 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ntpath 
>>> ntpath.relpath('foo ', 'foo')
'.'

On macOS:

Python 3.8.5 (v3.8.5:580fbb018f, Jul 20 2020, 12:11:27) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ntpath
>>> ntpath.relpath('foo ', 'foo')
'..\\foo '


I stumbled into this issue when troubleshooting an [issue in a Setuptools 
PR](https://github.com/pypa/setuptools/pull/2305#issuecomment-670946965).

I suspect the Windows version is using some API that strips whitespace from the 
filename before performing a relative path. However, when using relpath to 
detect characters after a common path, stripping the whitespace can cause 
problems.

I wouldn't expect Windows to be performing normalization of paths in relpath, 
but it seems it does. If this behavior is by design and has a good reason, that 
behavior should be mirrored in the non-Windows implementation.

--
components: Windows
messages: 375053
nosy: jaraco, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ntpath.relpath behaves differently on Windows with trailing spaces
versions: Python 3.8

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



[issue41350] Use of zipfile.Path causes attempt to write after ZipFile is closed

2020-07-24 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

This routine will repro the issue without relying on garbage collection to 
trigger the error:

```
import io
import zipfile
buf = io.BytesIO()
zf = zipfile.ZipFile(buf, mode='w')
zp = zipfile.Path(zf)
with zp.joinpath('zile-a').open('w') as fp:
fp.write('contents of file-a')
zf.close()
buf.close()
zp.root.close()
```

--

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



[issue41350] Use of zipfile.Path causes attempt to write after ZipFile is closed

2020-07-24 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I'm a little surprised from Nick's original post that the behavior is 
triggered. After all, the code [already has a protection for a 
previously-closed 
zipfile](https://github.com/python/cpython/blob/0dd98c2d00a75efbec19c2ed942923981bc06683/Lib/zipfile.py#L1812-L1813)
 and that value is [unconditionally set during 
close](https://github.com/python/cpython/blob/0dd98c2d00a75efbec19c2ed942923981bc06683/Lib/zipfile.py#L1828).
 So how is it that Zipfile.__del__ is being called?

Jeffrey suggests that

> a copy of the zip_file object is getting created, probably by the Path 
> constructor

And indeed, I can confirm the ZipFile [state is copied into a new object 
here](https://github.com/python/cpython/blob/0dd98c2d00a75efbec19c2ed942923981bc06683/Lib/zipfile.py#L2202).
 The FastLookup and CompleteDirs functionality is for performance optimizations.

> I created a simpler test case that exercises the buggy code.

Although the simpler test does trigger the error, I'd argue that the error is 
_expected_ in this case and that the zip file will be invalid because 
`self._write_end_record` will never get called.

I expected this example to more accurately capture the failure:

```
import io
import zipfile
buf = io.BytesIO()
zf = zipfile.ZipFile(buf, mode='w')
zp = zipfile.Path(zf)
with zp.joinpath('zile-a').open('w') as fp:
fp.write(b'contents of file-a')
zf.close()
zp.root.close()
```

But it does not. I'll need to do more investigation.

One option here is for `Path` to document that any zipfile passed to it is no 
longer valid and enforce that fact by disabling the original object passed to 
it.

Another approach could be to try to use an adapter pattern to adapt the 
original ZipFile rather than clone it into a subclass.

--

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



[issue41282] Deprecate and remove distutils

2020-07-12 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
nosy: +steve.dower

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



[issue41282] Deprecate and remove distutils

2020-07-12 Thread Jason R. Coombs

Jason R. Coombs  added the comment:

Łukasz, would it be possible to add the deprecation warning and documented 
deprecation to Python 3.9?

--
nosy: +lukasz.langa

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



[issue41282] Deprecate and remove distutils

2020-07-12 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
nosy: +ncoghlan, paul.moore

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



[issue41282] Deprecate and remove distutils

2020-07-12 Thread Jason R. Coombs


New submission from Jason R. Coombs :

Setuptools has adopted distutils as outlined in 
[pypa/packaging-problems#127](https://github.com/pypa/packaging-problems/issues/127).
 Although there are some straggling issues, the current release of Setuptools 
fully obviates distutils if a certain environment variable is set. Soon, that 
behavior will be default.

Additionally, the distutils codebase remains maintained at 
[pypa/distutils](https://github.com/pypa/distutils) in a form suitable for 
releasing as a third-party package, should the need arise (i.e. pip install 
distutils).

The plan now is to freeze, deprecate, and in Python N + 0.1, remove distutils.

Already, Setuptools is identifying emergent bugs and other defects in distutils 
and providing fixes for them (issue41207, 
[pypa/setuptools#2212](https://github.com/pypa/setuptools/issues/2212)). 
Keeping these changes in sync across three repos and different supported 
versions is tedious, so I'd like to move forward with the deprecation process 
as soon as possible.

--
components: Distutils
messages: 373548
nosy: dstufft, eric.araujo, jaraco
priority: normal
severity: normal
status: open
title: Deprecate and remove distutils
versions: Python 3.10, Python 3.9

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



[issue16396] Importing ctypes.wintypes on Linux gives a ValueError instead of an ImportError

2020-07-08 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +20542
pull_request: https://github.com/python/cpython/pull/21394

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



[issue16396] Importing ctypes.wintypes on Linux gives a ValueError instead of an ImportError

2020-07-07 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3, Python 
3.4

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



[issue41207] distutils.command.build_ext raises FileNotFoundError

2020-07-06 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
keywords: +patch
pull_requests: +20504
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21359

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



[issue41207] distutils.command.build_ext raises FileNotFoundError

2020-07-06 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I learned the magical incantation to port commits from pypa/distutils to 
CPython:

```
cpython bugfix/41207-rewrite-filenotfound $ git -C ~/p/pypa/distutils 
format-patch HEAD~2 --stdout | git am --directory Lib   
 
Applying: Add test for spawn when exe is missing. Ref pypa/distutils#3.
Applying: Replace OSError with DistutilsExecError. Fixes pypa/distutils#3 and 
pypa/setuptools#2228 and bpo-41207.
```

--

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



[issue41207] distutils.command.build_ext raises FileNotFoundError

2020-07-06 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Sure. I'll submit patches.

--

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



[issue41207] distutils.command.build_ext raises FileNotFoundError

2020-07-05 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

CPython should also consider [this 
change](https://github.com/pypa/distutils/commit/d9ba43436d), which unifies the 
`DEBUG` handling, consolidates the exception trapping, and uses 
`subprocess.check_call` to re-use exit code checking.

--

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



[issue41207] distutils.command.build_ext raises FileNotFoundError

2020-07-05 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

In 
[pypa/distutils@7aa5abeafc](https://github.com/pypa/distutils/commit/7aa5abeafc1e0b1b351c4c8ac7eb14c310366a46),
 I've pushed a fix (with a repro test in the parent commit). I recommend this 
fix be applied to CPython 3.9.

--

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



[issue18080] setting CC no longer overrides default linker for extension module builds on OS X

2020-07-04 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Well, the issue is potentially ignorable, especially if distutils is deprecated 
and removed from CPython. Alternately, CPython could adopt the [patch from 
distutils](https://github.com/pypa/distutils/pull/1/commits/c3a052aefbba0d5fda10790e676223c0dc12f0ed)
 that corrects the issue. Would you like me to file a separate bug for this 
issue? Or apply that patch? Or something else?

--

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



[issue41207] distutils.command.build_ext raises FileNotFoundError

2020-07-03 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
versions: +Python 3.10

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



[issue41207] distutils.command.build_ext raises FileNotFoundError

2020-07-03 Thread Jason R. Coombs


New submission from Jason R. Coombs :

In [pypa/setuptools#2228](https://github.com/pypa/setuptools/issues/2228), by 
adopting the distutils codebase from a late release of CPython, Setuptools 
stumbled onto an API-breaking change in distutils rooted at issue39763.

Details are in the Setuptools investigation, but to summarize:

- distutils.ccompiler.CCompiler.compile declares "raises CompileError on 
failure" and calls `self._compile`, implemented by subclasses.
- In at least `distutils.unixcompiler.UnixCCompiler._compile`, 
`distutils.spawn.spawn` is called (through CCompiler.spawn).
- Since GH-18743, `distutils.spawn.spawn` calls `subprocess.Popen` which raises 
FileNotFoundError when the target executable doesn't exist.
- Programs trapping CompileError but not FileNotFoundError will crash where 
once they had error handling.

Setuptools discovered this behavior in the 48.0 release when it incorporated 
these distutils changes into a vendored release of Setuptools, but the failures 
exhibited will apply to all builds (including pyyaml) on Python 3.9.

--
assignee: lukasz.langa
components: Distutils
keywords: 3.9regression
messages: 372973
nosy: dstufft, eric.araujo, jaraco, lukasz.langa
priority: release blocker
severity: normal
status: open
title: distutils.command.build_ext raises FileNotFoundError
type: crash
versions: Python 3.9

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



[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)

2020-07-03 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I've flagged issue41207 as a regression stemming from this effort.

--
nosy: +jaraco

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



[issue18080] setting CC no longer overrides default linker for extension module builds on OS X

2020-07-02 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

For easy reference, the relevant commit is 
https://github.com/python/cpython/commit/97345680dc.

--

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



[issue18080] setting CC no longer overrides default linker for extension module builds on OS X

2020-07-02 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

In [pypa/distutils#1](https://github.com/pypa/distutils/pull/1), I learned that 
the test doesn't have the intended effect. Patching `get_config_var()` has no 
effect because the function under test calls `get_config_vars()`. In some 
environments, such as PyPy3 as built on Homebrew, the first test fails.

--
nosy: +jaraco

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



[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

2020-06-21 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Yes, I generally agree with your assessment. Let me know if you have any 
questions about the implementation as you're exploring a solution.

--

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



[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

2020-06-21 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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



[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

2020-06-21 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

>>It seems you may have discovered a use-case that violates that expectation, a 
>>case where `/a.txt` is identical to `a.txt`.

> The thing is: it's not.

I think maybe you misunderstood. I mean that the zipfile you have seems to be 
treating `/a.txt` as a file `a.txt` at the root of the zipfile, identical to 
another zipfile that has an item named `a.txt`.

I'm not saying that zipfile.Path handles that situation; your example clearly 
contradicts that notion.

> I provided minimal example where archive created with zipfile.ZipFile itself 
> reproduces this behaviour. Just prerpend all paths with / an it does not work.

Thank you. I'm grateful for the minimal example. What I'm trying to assess here 
is the impact - how common is this use-case and should it be supported. One 
option here might be to document the library as not supporting files whose 
names begin with a leading slash.

Digging into [the 
spec](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT), Section 
4.4.17.1 explicitly states:

> The path stored MUST NOT contain a drive or device letter, or a leading slash.

It appears the file your client has sent and the minimal example you've 
generated represents an invalid zip file.

In [this branch](https://github.com/jaraco/zipp/tree/bugfix/bpo-41035), I 
started exploring what it would take to support this format. Unfortunately, 
just patching the namelist was not enough. Supporting this change interacts 
with behaviors across a number of methods, so would add substantial complexity 
to the implementation. It becomes inelegant to manage the position in the file 
(`.at` property) when there's ambiguity about the underlying format. It opens 
up lots of questions, like:

- should `at` include the leading slash?
- should the class support zip files with mixed leading and non-leading slashes?
- at what point does `Path` become aware of the format used?
- are there emergent performance concerns?

In other words, the design relies heavily on the assumption that there's one 
way to store a file and two ways to store a directory (explicitly and 
implicitly).

Based on these findings, I'm disinclined to support the format in the canonical 
Path implementation.

What I recommend is that you develop a subclass of zipfile.Path that supports 
the abnormal format, use that for your work, and publish it (perhaps here, 
perhaps as a library) for others with the same problem to use. If enough people 
report it having usefulness, then I'd definitely consider incorporating it into 
the library, either as a separate implementation or perhaps integrating it 
(especially if that can be done without substantially complicating the 
canonical implementation).

Alternately, ask if the client can generate valid zip files. I'm eager to hear 
your thoughts in light of my work. Can we close this as invalid?

--

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



[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

2020-06-21 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I created [jaraco/zipp#56](https://github.com/jaraco/zipp/issues/56) to track 
the issue in the backport.

--

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



[issue41035] zipfile.Path does not work properly with zip archives where paths start with /

2020-06-20 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Thanks sorrow for filing a report.

I primarily developed this functionality. As I did, I found the 'zip' format to 
be under-specified, so I used real-world examples as models to infer a spec.

It seems you may have discovered a use-case that violates that expectation, a 
case where `/a.txt` is identical to `a.txt`.

My instinct is that `zipfile.Path` should support 99% of real-world use-cases 
and that other use-cases may not be supported or may require additional 
consideration (wrappers, subclasses) to support.

Can you tell me more about your use-case and why zipp.Path/zipfile.Path should 
support it? Is this behavior a result of a real-world example (please share 
details about the origin) or contrived?

--

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



[issue40924] Recent importlib change breaks most recent certifi == 2020.4.5.2

2020-06-13 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +20049
pull_request: https://github.com/python/cpython/pull/20857

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



[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

2020-06-12 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Thanks for the notice Ned. I've revived the PR and addressed all the comments 
from Victor. Any chance this can get into Python 3.7?

--

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



[issue40924] Recent importlib change breaks most recent certifi == 2020.4.5.2

2020-06-11 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +20017
pull_request: https://github.com/python/cpython/pull/20820

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



[issue40924] Recent importlib change breaks most recent certifi == 2020.4.5.2

2020-06-10 Thread Jason R. Coombs

Jason R. Coombs  added the comment:

Thanks for the thorough and considerate response.

I do think your original recommendation of reverting the broken feature is the 
best approach at this point. That is, keep resources.files with the fallback 
shim and eliminate support for loaders supplying that behavior. That will avoid 
users relying on that protocol but enable the files feature for Source and Zip 
importers.

That will buy time for the remaining functionality, mainly the provider 
interface, to mature and possibly evolve further, for eventual adoption in a 
future Python release.

Some planning will need to be dialed back, but I don’t have confidence in the 
implementation to say that it’s the best one. Better to defer that effort.

I’ll put together a patch for 3.9 to remove the loader support (backward 
incompatible with b1/2 but compatible with 3.8 but only for custom loaders), 
and put together a hot fix for master so it’s no longer broken.

--

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



[issue40924] Recent importlib change breaks most recent certifi == 2020.4.5.2

2020-06-09 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I feel terrible and really regret that this was able to break things so badly.

What options are available at this point? I'd at the very least like to remove 
the `loader.files()` behavior to avoid encouraging other loaders to implement 
it. Should we also revert the `resources.files()` feature altogether, as you 
suggested?

--
stage: needs patch -> patch review

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



[issue40924] Recent importlib change breaks most recent certifi == 2020.4.5.2

2020-06-09 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

This issue stems from improper reliance on implementation details of 
`importlib.resources.path`, which returns a context manager that is designed to 
clean up the file after the context closes. certifi would have encountered the 
same problem on older Pythons if certifi had been installed as a zip egg or 
other non-filesystem-based package.

That said, it is also undesirable for path no longer to return a reference to 
an existing path when one exists. That behavior has come about as the 
importlib.resources API moves from the legacy implementation to the new one 
based on TraversableResources (files function).

I encountered [a similar 
issue](https://github.com/python/cpython/pull/20576#issuecomment-637881341) 
during the original submission, which I addressed by removing the same 
assumption from another library (importlib.metadata).

I believe the best fix here is to restore that assumption while retaining other 
important changes in this patch. Should this assumed behavior also be tested 
(guaranteed)? That I'm less sure about.

> Please respect the beta feature freeze.

I do respect the beta feature freeze. The relevant feature was added prior to 
b1. The reverted change is an incremental fix addressing underlying 
implementation details such as how resources are resolved and removing 
duplicate code paths.

More importantly, the change also addresses a [key interface 
problem](https://github.com/python/cpython/pull/20576#issuecomment-639954228) 
that I identified in b1 - that the previously advertised interface of `loaders` 
supplying `files()` methods is inadequate.

I've put a lot of effort into pulling this all together for 3.9 (three full 
days just this past weekend and hundreds of hours leading up to that). It would 
be a real shame for it to be released in a broken state due to a minor (though 
admittedly impactful) hiccup.

I suspect there's a small change that to the submitted patch that will restore 
the prior expectation and leave the codebase in a healthier state.

I'll prepare that soon.

--

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



[issue40924] Recent importlib change breaks most recent certifi == 2020.4.5.2

2020-06-09 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I understand the issue here and can supply more details soon (no later than 
this weekend).

--

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



[issue39791] New `files()` api from importlib_resources.

2020-06-07 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset 843c27765652e2322011fb3e5d88f4837de38c06 by Jason R. Coombs in 
branch 'master':
bpo-39791 native hooks for importlib.resources.files (GH-20576)
https://github.com/python/cpython/commit/843c27765652e2322011fb3e5d88f4837de38c06


--

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



[issue39791] New `files()` api from importlib_resources.

2020-06-07 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset 2efe18bf277dd0f38a1d248ae6bdd30947c26880 by Jason R. Coombs in 
branch 'master':
bpo-39791: Support file systems that cannot support non-ascii filenames 
(skipping tests in that case). (#20681)
https://github.com/python/cpython/commit/2efe18bf277dd0f38a1d248ae6bdd30947c26880


--

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



[issue39791] New `files()` api from importlib_resources.

2020-06-06 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

See GH-20681 for a proposed fix. I've scheduled the build bots to run the 
patch. Will build bots prove the fix? If not, can you test the patch in the 
same environment where it was discovered?

--

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



[issue39791] New `files()` api from importlib_resources.

2020-06-06 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +19894
pull_request: https://github.com/python/cpython/pull/20681

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



[issue39791] New `files()` api from importlib_resources.

2020-06-06 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Thanks for the report Michael. I'm trying to figure out the best way to address 
the issue. That test is shared with importlib_metadata, so needs to run without 
CPython's test suite fixtures, such as the ones that generate non-ascii 
filenames. I'm tempted to just attempt to create the fixture and skip if the 
fixture fails. An alternate approach might be to attempt to load CPython's 
fixture, skip if that value is None, and fallback to the snowman otherwise.

--

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



[issue39791] New `files()` api from importlib_resources.

2020-06-05 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset a4fa9a95153a3800dea60b3029b2dcaf8a4f6acb by Miss Islington (bot) 
in branch '3.9':
bpo-39791: Refresh importlib.metadata from importlib_metadata 1.6.1. (GH-20659) 
(GH-20661)
https://github.com/python/cpython/commit/a4fa9a95153a3800dea60b3029b2dcaf8a4f6acb


--

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



[issue39791] New `files()` api from importlib_resources.

2020-06-05 Thread Jason R. Coombs


Jason R. Coombs  added the comment:


New changeset 161541ab45278df6603dd870113b10f13e4d9e16 by Jason R. Coombs in 
branch 'master':
bpo-39791: Refresh importlib.metadata from importlib_metadata 1.6.1. (GH-20659)
https://github.com/python/cpython/commit/161541ab45278df6603dd870113b10f13e4d9e16


--

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



[issue39791] New `files()` api from importlib_resources.

2020-06-05 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +19878
pull_request: https://github.com/python/cpython/pull/20659

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



[issue39791] New `files()` api from importlib_resources.

2020-06-05 Thread Jason R. Coombs


Change by Jason R. Coombs :


--
pull_requests: +19875
pull_request: https://github.com/python/cpython/pull/20656

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



[issue40840] lzma.h file not found building on macOS

2020-06-03 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

In [this latest 
routine](https://github.com/jaraco/jaraco.develop/blob/6469c7a61e7349b93f191df38eed6cd020dd79be/jaraco/develop/macos-build-python.py),
 on my macOS workstation with Homebrew installed locally, Python builds 
successfully with just a few outliers:

```
Python build finished successfully!
The necessary bits to build these optional modules were not found:
_gdbm ossaudiodev   spwd   
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.


The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc  atexitpwd
time   
```

The output is the same as on the system with Homebrew system-installed, except 
for `_gdbm`, which seems only to work on system-installed Homebrew.

That's much cleaner and addresses the reported issue. I guess I should have 
been more careful to execute exactly what the dev docs said rather than my 
routine which must have accumulated some cruft as you recognized.

Thanks for the help.

If you have any other hints as to how to ensure _gdbm builds, I'm open to 
suggestions. Thanks.

--

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



[issue40840] lzma.h file not found building on macOS

2020-06-01 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

In [this 
commit](https://github.com/jaraco/jaraco.develop/commit/e3e5f66ca6693d8ec3abd31d99d491f6dfa1f67d),
 I include "xz" in the routine. Should Python's developer docs include 
something like that to ensure compatibility?

--

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



[issue40840] lzma.h file not found building on macOS

2020-06-01 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

This issue doesn't happen on my mac that installs homebrew globally. Do the 
build instructions assume Homebrew is installed system-wide?

--

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



  1   2   3   4   5   6   7   8   9   10   >