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.or
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
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
Jason R. Coombs added the comment:
Yes - I keep both in sync.
--
___
Python tracker
<https://bugs.python.org/issue42382>
___
___
Python-bugs-list mailin
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
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
Change by Jason R. Coombs :
--
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue37788>
___
___
Python-bugs-list mailing list
Unsubscribe:
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-3640
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
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/issue37
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
Change by Jason R. Coombs :
--
pull_requests: +22043
pull_request: https://github.com/python/cpython/pull/23127
___
Python tracker
<https://bugs.python.org/issue37
Change by Jason R. Coombs :
--
pull_requests: +22024
pull_request: https://github.com/python/cpython/pull/23107
___
Python tracker
<https://bugs.python.org/issue37
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>
___
___
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
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/issue42
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/issu
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/issu
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/issu
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
Change by Jason R. Coombs :
--
assignee: -> jaraco
___
Python tracker
<https://bugs.python.org/issue42163>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Jason R. Coombs :
--
stage: patch review -> commit review
___
Python tracker
<https://bugs.python.org/issue42090>
___
___
Python-bugs-list mai
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/issu
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
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/i
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
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
Change by Jason R. Coombs :
--
pull_requests: +21845
pull_request: https://github.com/python/cpython/pull/22915
___
Python tracker
<https://bugs.python.org/issue41
Change by Jason R. Coombs :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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.
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
Change by Jason R. Coombs :
--
pull_requests: +21684
pull_request: https://github.com/python/cpython/pull/22716
___
Python tracker
<https://bugs.python.org/issue42
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
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
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/issue21
Change by Jason R. Coombs :
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue40564>
___
___
Python-bugs-list mailing list
Unsubscrib
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 -Pyth
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
Change by Jason R. Coombs :
--
pull_requests: +21444
pull_request: https://github.com/python/cpython/pull/22404
___
Python tracker
<https://bugs.python.org/issue41
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/issu
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
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
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
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/issu
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
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 se
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
Change by Jason R. Coombs :
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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.
--
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/issue41
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
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
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
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
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
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
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
>>
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
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
Change by Jason R. Coombs :
--
nosy: +steve.dower
___
Python tracker
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue41
Change by Jason R. Coombs :
--
nosy: +ncoghlan, paul.moore
___
Python tracker
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsub
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
Change by Jason R. Coombs :
--
pull_requests: +20542
pull_request: https://github.com/python/cpython/pull/21394
___
Python tracker
<https://bugs.python.org/issue16
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/issue16
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/issu
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
Jason R. Coombs added the comment:
Sure. I'll submit patches.
--
___
Python tracker
<https://bugs.python.org/issue41207>
___
___
Python-bugs-list mailin
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
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
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
Change by Jason R. Coombs :
--
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue41207>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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/issue39
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/issue18
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
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/issue41
Change by Jason R. Coombs :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
t
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/issue41
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
Change by Jason R. Coombs :
--
pull_requests: +20049
pull_request: https://github.com/python/cpython/pull/20857
___
Python tracker
<https://bugs.python.org/issue40
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/issue37
Change by Jason R. Coombs :
--
pull_requests: +20017
pull_request: https://github.com/python/cpython/pull/20820
___
Python tracker
<https://bugs.python.org/issue40
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
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
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
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/issue40
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
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
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
Change by Jason R. Coombs :
--
pull_requests: +19894
pull_request: https://github.com/python/cpython/pull/20681
___
Python tracker
<https://bugs.python.org/issue39
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
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
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
Change by Jason R. Coombs :
--
pull_requests: +19878
pull_request: https://github.com/python/cpython/pull/20659
___
Python tracker
<https://bugs.python.org/issue39
Change by Jason R. Coombs :
--
pull_requests: +19875
pull_request: https://github.com/python/cpython/pull/20656
___
Python tracker
<https://bugs.python.org/issue39
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
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 com
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/issue40
401 - 500 of 1492 matches
Mail list logo
