[issue46126] Unittest output drives developers to avoid docstrings
Change by Jason R. Coombs : -- pull_requests: +30349 pull_request: https://github.com/python/cpython/pull/32288 ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47142] Document importlib.resources.abc.Traversable
Jason R. Coombs added the comment: Correction. In msg416618, link should have been: [docs for zipfile](https://docs.python.org/3/library/zipfile.html#zipinfo-objects) -- ___ Python tracker <https://bugs.python.org/issue47142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47142] Document importlib.resources.abc.Traversable
Jason R. Coombs added the comment: > Are the methods expected to raise specific exception types (e.g. if a > resource is missing, or you call iterdir on a “file”)? The short answer is no. The protocol does not stipulate specific exceptions. Perhaps it should be documented that any exceptions that occur when accessing the backing resource will propagate. Although, I do believe that statement is true for all Python code unless stated otherwise. I agree it would be nice if the protocol could stipulate which exceptions might be raised by a given implementation, but I'm not confident that's possible, at least not without wrapping/adapting the pathlib.Path and zipfile.Path objects. Does that answer the question? Are you working on another provider that implements this protocol? I'd be happy to consult on that effort. -- ___ Python tracker <https://bugs.python.org/issue47142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47142] Document importlib.resources.abc.Traversable
Jason R. Coombs added the comment: > Can the argument to `joinpath` contain path separators? Good question. Currently, I'm aware of three concrete implementations of Traversable.joinpath: - pathlib.Path.joinpath - zipfile.Path.joinpath - importlib.resources.simple.ResourceContainer.joinpath ``Traversable.joinpath`` was modeled after ``pathlib.Path.joinpath``, which itself is itself not rigorous in what path separators are allowed. The [docstring](https://github.com/python/cpython/blob/3faa9f78d4b9a8c0fd4657b434bdb08ae1f28800/Lib/pathlib.py#L754-L758) does indicate that each of the parameters will be combined with the existing path and acknowledges that absolute paths are possible. The [curated docs](https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.joinpath) only give examples, and curiously, those examples only use posixpath.sep, suggesting that it's recommended when passing compound paths to use posixpath separators as they're more widely supported. For zipfile.Path, I observe that [joinpath does accept path separators](https://github.com/python/cpython/blob/3faa9f78d4b9a8c0fd4657b434bdb08ae1f28800/Lib/zipfile.py#L2438-L2440) but looking at the [docs for zipfile](https://gist.github.com/jaraco/5b266870c62680d6d6b3a876be321fa4), it's not even obvious to me what path separators are used in zipfiles, but I do observe there is [coercion to posixpath.sep](https://gist.github.com/jaraco/5b266870c62680d6d6b3a876be321fa4). ``ResourceContainer``, on the other hand, [will not accept path separators](https://github.com/python/cpython/blob/3faa9f78d4b9a8c0fd4657b434bdb08ae1f28800/Lib/importlib/resources/simple.py#L102-L105). This class, however, may not be used anywhere and probably could be extended to support path separators as well. Here's what I propose: - First, document that the interface is under-specified and that for maximum compatibility, a consumer should pass only relative paths using posixpath.sep or no separator at all. Additionally, explicitly declare that behavior with absolute paths is undefined and unsupported. - Second, expand the interface on ``Traversable.joinpath`` to stipulate that the interface should accept multiple relative paths. - Third, ``simple.ResourceContainer`` should be updated to meet that spec. -- ___ Python tracker <https://bugs.python.org/issue47142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47142] Document importlib.resources.abc.Traversable
Change by Jason R. Coombs : -- assignee: docs@python -> jaraco ___ Python tracker <https://bugs.python.org/issue47142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: My goal with this issue is to simply unblock the use of docstrings in Python tests. I believe with the work above and the proposed published post, I've accomplished that goal. I've already spent more time than I'd hoped on this issue and would like to resolve it at its original scope. I do see how this issue reveals some deficiencies with the current UI/UX, and I'd welcome a separate feature request to address those deficiencies. I'll even help draft the bug report on request. -- ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Change by Jason R. Coombs : -- pull_requests: +30208 pull_request: https://github.com/python/cpython/pull/32128 ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Change by Jason R. Coombs : -- resolution: -> works for me ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment:
I've confirmed that prior to the patch in PR 30194, the location of the failure
was indeed reported. It was just not reported on the same line:
```
cpython main $ git log -1
commit 3e93af0b06cada874c4a16868b6f863b599919f2 (HEAD -> main)
Author: Jason R. Coombs
Date: Sat Mar 26 10:45:58 2022 -0400
Revert "bpo-46126: Disable 'descriptions' when running tests internally.
(GH-30194)"
This reverts commit a941e5927f7f2540946813606c61c6aea38db426.
cpython main $ git diff
diff --git a/Lib/test/test_importlib/test_metadata_api.py
b/Lib/test/test_importlib/test_metadata_api.py
index b3627cbb75..7e3bb09cf2 100644
--- a/Lib/test/test_importlib/test_metadata_api.py
+++ b/Lib/test/test_importlib/test_metadata_api.py
@@ -90,8 +90,11 @@ def test_entry_points_distribution(self):
self.assertEqual(ep.dist.version, "1.0.0")
def test_entry_points_unique_packages(self):
-# Entry points should only be exposed for the first package
-# on sys.path with a given name.
+"""
+Entry points should only be exposed for the first package
+on sys.path with a given name.
+"""
+raise ValueError("Failing on purpose")
alt_site_dir = self.fixtures.enter_context(fixtures.tempdir())
self.fixtures.enter_context(self.add_sys_path(alt_site_dir))
alt_pkg = {
cpython main $ ./python.exe -E -We -m test -v test_importlib | grep
entry_points_unique_packages
test_entry_points_unique_packages
(test.test_importlib.test_metadata_api.APITests)
ERROR: test_entry_points_unique_packages
(test.test_importlib.test_metadata_api.APITests)
File
"/Users/jaraco/code/public/cpython/Lib/test/test_importlib/test_metadata_api.py",
line 97, in test_entry_points_unique_packages
test test_importlib failed
```
The description is given _in addition_ to the location of the test.
That means the concern reported in #302 was actually invalid.
I also was under the false impression that the description was masking the test
location, but instead, it's just enhancing it (while also injecting a newline).
Given this renewed understanding, I believe it's appropriate to back out the PR.
> I think the situation and the discussion should be summarized on python-dev!
Great suggestion. Will do.
--
___
Python tracker
<https://bugs.python.org/issue46126>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46975] clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
Jason R. Coombs added the comment: It's possible my bad experience may have been avoided through issue35905. -- ___ Python tracker <https://bugs.python.org/issue46975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46975] clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
Jason R. Coombs added the comment: Aha. If I configure/make without LDFLAGS or CPPFLAGS set, compilation works. Then I noticed for `LDFLAGS`, some users were using `-L`. I thought it was slightly odd that my recipe was using `-I` for both flags. How is it that [this mistake](https://github.com/jaraco/jaraco.develop/commit/6469c7a61e7349b93f191df38eed6cd020dd79be) hasn't caused me any grief until M1 build? No matter - correcting for that mistake and passing the correct LDFLAGS flag (-L) corrects for the issue. -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue46975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46975] clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
Jason R. Coombs added the comment: As suggested, I uninstalled and reinstalled everything in homebrew: $ brew list | xargs brew remove $ brew install python@3.10 python-launcher python@3.9 python@3.8 gh git Even after following those steps and setting LDFLAGS and CPPFLAGS to point to `brew --prefix`, the errors continue when running `./configure; make` in a clean checkout. -- ___ Python tracker <https://bugs.python.org/issue46975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46975] clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
Jason R. Coombs added the comment: I did [this search](https://www.google.com/search?q=gittext+homebrew+"ld%3A+symbol(s)+not+found+for+architecture+arm64"), which surfaced a few related results. [This article](https://lifesaver.codes/answer/pyenv-arm64-builds-confused-by-x86-64-libintl-in-usr-local-1877) seemed promising, but the symptoms there are different than mine. I don't have any gettext libs showing up in /usr/local (only in /opt/homebrew as expected). I noticed [this comment](https://github.com/pyenv/pyenv/issues/1877#issuecomment-976583556) reports the same issue I have, but no solution is present. I saw a suggestion to [set FLAGS](https://github.com/pyenv/pyenv/issues/1877#issuecomment-836115970), but I do that [as a matter of course](https://github.com/jaraco/jaraco.develop/blob/d3e524362ba15f87790f4c6279b1f92c06901387/jaraco/develop/macos-build-python.py#L38-L42). I don't have an x86 install of homebrew. This machine is less than a month old and has had ARM-based homebrew installed from the beginning. I'll keep investigating. -- ___ Python tracker <https://bugs.python.org/issue46975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46975] clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
Jason R. Coombs added the comment: SG. Thanks for the advice. I'll dive in and experiment and report back when I have progress. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue46975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46975] clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
Jason R. Coombs added the comment: Well, I'm using a mac with gettext installed as part of `brew install git` with homebrew installed using the standard procedure. Only after running `brew remove --ignore-dependencies gettext` and re-running configure/make did the command build, but doing so also broke features of git (I noticed that the branch name disappeared from my shell). I was able to reinstall git and gettext, but then configure/make failed. Do you have any advice on how to "properly install" gettext using homebrew on an M1 mac? -- ___ Python tracker <https://bugs.python.org/issue46975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment:
And indeed, after removing the `grep ERROR` part of the repro, even the repro
seems to be invalid:
```
cpython main $ ./python.exe -m test.test_importlib -v -k
test_entry_points_unique
test_entry_points_unique_packages
(test.test_importlib.test_metadata_api.APITests)
Entry points should only be exposed for the first package ... ERROR
test.test_importlib.test_windows (unittest.loader.ModuleSkipped) ... skipped
"No module named 'winreg'"
==
ERROR: test_entry_points_unique_packages
(test.test_importlib.test_metadata_api.APITests)
Entry points should only be exposed for the first package
--
Traceback (most recent call last):
File
"/Users/jaraco/code/public/cpython/Lib/test/test_importlib/test_metadata_api.py",
line 97, in test_entry_points_unique_packages
raise ValueError("Failing on purpose")
^^
ValueError: Failing on purpose
--
Ran 2 tests in 0.006s
FAILED (errors=1, skipped=1)
```
I'm effectively unable to replicate the behavior reported by Brett in the other
issue (unless `| grep ERROR` is consider an important use-case to support).
At this point, I propose one of two options:
1. Back out PR 30194 and restore the prior behavior with descriptions.
2. Leave PR 30194 to suppress descriptions for the default runner.
And then simply declare that docstrings are acceptable for CPython tests.
Given that descriptions are on by default, I'm slightly inclined toward (1).
Thoughts?
--
___
Python tracker
<https://bugs.python.org/issue46126>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46975] clang: error: linker command failed with exit code 1 (use -v to see invocation) on m1 mac
Jason R. Coombs added the comment: I ran into this same issue. I notice that gettext is a dependency of git, so a common dependency when developing. Is there perhaps a way that CPython could be made to ignore gettext on macos Silicon or to detect an incompatible platform and thus ignore it? -- nosy: +jaraco status: closed -> open ___ Python tracker <https://bugs.python.org/issue46975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: Inada, you're right. Good catch. I think I missed that behavior from before because I used `grep ERROR` and when I ran it this time, I just assumed the output would be the same, but it's clear that even _with descriptions enabled_, the location of the test is clearly reported in the case of launching with `-m unittest`. I'm now suspicious that my report in https://bugs.python.org/issue46126#msg408882 was also flawed as it uses `grep ERROR`, which could easily mask lines that adjacent to the error. I now believe that there are no concerns relating to Terry's concern, and likely not Brett's concern despite my best efforts to replicate. I'll bring back the original example and see if it in fact has the reported defect. -- assignee: terry.reedy -> jaraco ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment:
In an attempt to replicate Terry's usage, I added the following patch:
```
diff --git a/Lib/idlelib/idle_test/test_text.py
b/Lib/idlelib/idle_test/test_text.py
index 0f31179e04..be977bbfff 100644
--- a/Lib/idlelib/idle_test/test_text.py
+++ b/Lib/idlelib/idle_test/test_text.py
@@ -20,6 +20,10 @@ def test_init(self):
self.assertEqual(self.text.get('end'), '')
def test_index_empty(self):
+"""
+Failing test with bad description.
+"""
+raise ValueError()
index = self.text.index
for dex in (-1.0, 0.3, '1.-1', '1.0', '1.0 lineend', '1.end', '1.33',
```
When I did, I then ran the tests using the `-m` launcher:
```
$ ./python.exe -m test.test_idle -v -k test_index_empty
idlelib.idle_test.test_configdialog (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_debugger (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_editmenu (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_help (unittest.loader.ModuleSkipped) ... skipped 'cannot
run without OS X gui process'
idlelib.idle_test.test_parenmatch (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_percolator (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_replace (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_scrolledlist (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_search (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
test_index_empty (idlelib.idle_test.test_text.MockTextTest)
Failing test with bad description. ... ERROR
setUpClass (idlelib.idle_test.test_text.TkTextTest) ... skipped 'cannot run
without OS X gui process'
idlelib.idle_test.test_textview (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_tooltip (unittest.loader.ModuleSkipped) ... skipped
'cannot run without OS X gui process'
idlelib.idle_test.test_tree (unittest.loader.ModuleSkipped) ... skipped 'cannot
run without OS X gui process'
idlelib.idle_test.test_undo (unittest.loader.ModuleSkipped) ... skipped 'cannot
run without OS X gui process'
==
ERROR: test_index_empty (idlelib.idle_test.test_text.MockTextTest)
Failing test with bad description.
--
Traceback (most recent call last):
File "/Users/jaraco/code/public/cpython/Lib/idlelib/idle_test/test_text.py",
line 26, in test_index_empty
raise ValueError()
^^
ValueError
--
Ran 14 tests in 0.001s
FAILED (errors=1, skipped=14)
```
As you can see, the location of the failing test in the log is masked, and
instead the description is present.
I've pushed
https://github.com/python/cpython/tree/bpo-46126/disable-descriptions-unittest-m,
which when applied disables the descriptions.
This approach works as a surgical intervention, wrapping `unittest.main` in
such a way that it could be replaced across the test suite to disable
descriptions. By subclassing the TextTestRunner, it continues to honor other
parameters from the command-line (such as verbosity).
Terry, would you review the concept? Does it meet your needs? If so, I can
apply it more broadly and prepare a PR.
--
assignee: jaraco -> terry.reedy
___
Python tracker
<https://bugs.python.org/issue46126>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46125] Test the preferred API instead of relying on legacy for coverage
Change by Jason R. Coombs : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35967] Better platform.processor support
Jason R. Coombs added the comment: I'm going to close this issue again, as the implementation is now present in at least a couple of releases. May I suggest that if there are ongoing concerns or issues to open up a new issue and reference this one and loop me into the conversation? I'm also happy to re-open this one as well. -- resolution: -> fixed status: open -> closed ___ Python tracker <https://bugs.python.org/issue35967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46774] Importlib.metadata.version picks first distribution not latest
Jason R. Coombs added the comment: Closing without prejudice. Happy to revisit if there's more information on how importlib could/should behave differently. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47060] importlib.metadata.version can return None
Change by Jason R. Coombs : -- assignee: -> jaraco ___ Python tracker <https://bugs.python.org/issue47060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47060] importlib.metadata.version can return None
Jason R. Coombs added the comment:
Thanks for the report.
Yes, the issues are related, where .version and .name returning None are
specific manifestations of the metadata not having that key and the behavior
being ill-defined.
I haven't yet decided if metadata items being undefined should result in None
or raise an Exception (maybe KeyError).
For the specific case of a missing Name or Version, however, the packaging spec
says that these fields are required
(https://packaging.python.org/en/latest/specifications/core-metadata/#core-metadata-specifications),
so it may be reasonable for the behavior when the specification is not met
that the resulting behavior would be undefined (i.e. importlib.metadata should
be able to assume the specification). It's outside the scope of
importlib.metadata to detect, report, and repair invalid metadata. I would
welcome and even encourage a third-party package to take on the responsibility
of validating all distributions in an environment and reporting on
non-compliant aspects.
In that sense, the type declaration is correct. `.name` and `.version` should
always return `str` or raise an exception.
This additional example leads me stronger toward the position that
`.metadata[missing]` should raise a KeyError, which would also fix this issue.
I'd also argue that if the metadata file is missing altogether, that should
perhaps be a different error. That is, missing metadata is different from null
metadata. Right now, the two are indistinguishable from the interface.
> I'd expect there to be a PackageNotFoundError raised in this situation
That doesn't sound quite right to me. If there's a `.dist-info` directory, that
implies a package is present. e.g.:
```
~ $ mkdir foo.dist-info
~ $ py -c "import importlib.metadata as md; print(md.distribution('foo'))"
```
I'm going to ponder this one some more and probably address the `.metadata`
issue(s) first before making any pronouncements on the best approach here.
--
___
Python tracker
<https://bugs.python.org/issue47060>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47025] bytes do not work on sys.path
Jason R. Coombs added the comment: I'd advocate for not supporting bytes paths and instead updating the documentation to require strings. -- nosy: +jaraco ___ Python tracker <https://bugs.python.org/issue47025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47013] test_bdb and test_distutils fail on installed Python 3.9, 3.10 and 3.11 (setuptools 60.9.3, pip 22.0.4)
Jason R. Coombs added the comment: See https://github.com/pypa/setuptools/issues/3007#issuecomment-1068621865 where I did a brief analysis and probable explanation. What it boils down to: Setuptools needs to supply its own copy of distutils aggressively. It provides an opt out for this behavior and is able to offer built in opt out based on whatever signal is available. The default opt out is the SETUPTOOLS_USE_DISTUTILS=stdlib env var. for CPython, it also disables the behavior when ./pybuilddir.txt is present, but installed Pythons probably don’t have this config. Can those test runners be updated to set this environment variable? -- ___ Python tracker <https://bugs.python.org/issue47013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46246] importlib.metadata.DeprecatedList appears to be missing __slots__
Change by Jason R. Coombs : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
Change by Jason R. Coombs : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
Jason R. Coombs added the comment: New changeset 177be52517da9a876a3f9e670f88c4731b906986 by Jason R. Coombs in branch '3.9': [3.9] bpo-47004: Sync with importlib_metadata 4.11.3. (GH-31854). (GH-31859) https://github.com/python/cpython/commit/177be52517da9a876a3f9e670f88c4731b906986 -- ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
Jason R. Coombs added the comment: New changeset d929aa70e2a324ea48fed221c3257f929be05115 by Jason R. Coombs in branch '3.10': [3.10] bpo-47004: Sync with importlib_metadata 4.11.3. (GH-31854). (GH-31857) https://github.com/python/cpython/commit/d929aa70e2a324ea48fed221c3257f929be05115 -- ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
Change by Jason R. Coombs : -- pull_requests: +29957 pull_request: https://github.com/python/cpython/pull/31859 ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
Change by Jason R. Coombs : -- pull_requests: +29955 pull_request: https://github.com/python/cpython/pull/31857 ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
Jason R. Coombs added the comment: New changeset b1e286860742e7ba6fadc75e3ddb6c2899a56919 by Jason R. Coombs in branch 'main': bpo-47004: Sync with importlib_metadata 4.11.3. (#31854) https://github.com/python/cpython/commit/b1e286860742e7ba6fadc75e3ddb6c2899a56919 -- ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
Change by Jason R. Coombs : -- keywords: +patch pull_requests: +29952 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31854 ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
New submission from Jason R. Coombs : Importlib_metadata 4.11.1-3 introduced a few bug fixes. Importantly, 4.11.2 fixed a [serious defect](https://github.com/python/importlib_metadata/issues/369). Let's incorporate those fixes into CPython. -- messages: 415075 nosy: jaraco priority: normal severity: normal status: open title: Apply bugfixes from importlib_metadata 4.11.3. versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47004] Apply bugfixes from importlib_metadata 4.11.3.
Change by Jason R. Coombs : -- assignee: -> jaraco ___ Python tracker <https://bugs.python.org/issue47004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46774] Importlib.metadata.version picks first distribution not latest
Jason R. Coombs added the comment: Aha. I learned how to run commands in the poetry environment... and how to locate files in that environment. With that, I figured out where the environment is and where the package metadata is coming from: ``` $ docker run -it @$(docker build -q .) bash -c 'ls $(poetry env info -p)/lib/python3.10/site-packages/poetry*' /root/.cache/pypoetry/virtualenvs/poetry-remove-untracked-Qran5nGc-py3.10/lib/python3.10/site-packages/poetry_remove_untracked.pth /root/.cache/pypoetry/virtualenvs/poetry-remove-untracked-Qran5nGc-py3.10/lib/python3.10/site-packages/poetry_remove_untracked-0.1.0.dist-info: INSTALLER METADATA RECORD /root/.cache/pypoetry/virtualenvs/poetry-remove-untracked-Qran5nGc-py3.10/lib/python3.10/site-packages/poetry_remove_untracked-0.2.0.dist-info: INSTALLER METADATA RECORD ``` In this case, it's clear there is metadata for the `poetry-remove-untracked` package in duplicate, and importlib.metadata loads that metadata in whatever order the operating system provides it (lexicographic alphabetic sort usually). `importlib.metadata` doesn't have any means to determine which of those metadata are appropriate and doesn't support multiple versions of the same distribution being installed into the same path. Since poetry has acknowledged this issue is a bug, I suspect there's nothing more for importlib.metadata to do here, but do please report back if you have different expectations. -- ___ Python tracker <https://bugs.python.org/issue46774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46774] Importlib.metadata.version picks first distribution not latest
Jason R. Coombs added the comment:
The behavior you describe is intentional _and_ deterministic. The library
discovers distributions in the order found based on the search path provided,
with the search path defaulting to sys.path.
The expectation is therefore that the metadata should be discovered in its
order of precedence.
Thanks for the repro. I attempted to follow it, but was unsuccessful:
```
FROM jaraco/multipy-tox
RUN git clone https://github.com/kkirsche/poetry-remove-untracked
RUN pip install poetry
WORKDIR poetry-remove-untracked
RUN git checkout before
RUN poetry install --remove-untracked
RUN git checkout after
RUN poetry install --remove-untracked
CMD python -c "import importlib.metadata as md;
print(md.version('poetry-remove-untracked'))"
```
Running that Dockerfile reports that the package isn't installed.
```
draft $ docker run -it @$(docker build -q .)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 955, in
version
return distribution(distribution_name).version
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 928, in
distribution
return Distribution.from_name(distribution_name)
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 518, in
from_name
raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: No package metadata was found for
poetry-remove-untracked
```
I think you'll have to teach me a bit about how poetry works in order to
understand how to properly reproduce the issue so I can examine the relevant
environment.
--
___
Python tracker
<https://bugs.python.org/issue46774>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32642] add support for path-like objects in sys.path
Jason R. Coombs added the comment: I'm in support of adding Path support for sys.path, but I also agree with Eric, there are innumerable consumers of sys.path beyond importlib. and since pathlib.Path isn't a str, it would likely introduce incompatibility. On the other hand, users introducing Path objects to sys.path could be warned that although importlib supports Path objects, other consumers may not, and that support for it in importlib isn't endorsement of the use of those types and the consequences aren't necessarily supported. As an aside, it's too bad a Path object couldn't have been a str subclass (as it is for [path](https://pypi.org/project/path), which would have made problems like this one much safer to solve. -- nosy: +jaraco ___ Python tracker <https://bugs.python.org/issue32642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46246] importlib.metadata.DeprecatedList appears to be missing __slots__
Jason R. Coombs added the comment: I'm pretty sure both EntryPoints and DeprecatedList were introduced in Python 3.10, so 3.9 and 3.8 aren't relevant. -- versions: -Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13305] datetime.strftime("%Y") not consistent for years < 1000
Jason R. Coombs added the comment: The tempora library implements a [portable strftime](https://tempora.readthedocs.io/en/latest/index.html#tempora.strftime). -- ___ Python tracker <https://bugs.python.org/issue13305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46619] lazy module property not recognized by doctests
New submission from Jason R. Coombs : Attempting to define a lazy-loaded property for a module, I found [this guidance](https://stackoverflow.com/a/52018676/70170) referencing [module attribute access](https://docs.python.org/3/reference/datamodel.html#customizing-module-attribute-access) in the Python docs as a means of customizing attribute access. I followed that guidance, but found that doctests don't have access to those attributes in its execution. Consider this reproducer: ``` """ >>> print(static_property) static value >>> print(lazy_property) lazy value """ # text.py import types import sys static_property = 'static value' class _Properties(types.ModuleType): @property def lazy_property(self): return 'lazy value' sys.modules[__name__].__class__ = _Properties ``` Run that with `python -m doctest text.py` and it fails thus: ``` ** File "/Users/jaraco/draft/text.py", line 4, in text Failed example: print(lazy_property) Exception raised: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/doctest.py", line 1346, in __run exec(compile(example.source, filename, "single", File "", line 1, in print(lazy_property) NameError: name 'lazy_property' is not defined ** 1 items had failures: 1 of 2 in text ***Test Failed*** 1 failures. ``` Same error using the `__getattr__` technique: ``` """ >>> print(static_property) static value >>> print(lazy_property) lazy value """ static_property = 'static value' def __getattr__(name): if name != 'lazy_property': raise AttributeError(name) return 'lazy value' ``` I suspect the issue is that doctests runs with locals from the module's globals(), which won't include these lazy properties. It would be nice if doctests could honor locals that would represent the properties available on the module. -- components: Library (Lib) messages: 412409 nosy: jaraco priority: normal severity: normal status: open title: lazy module property not recognized by doctests versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46546] `importlib.metadata.DeprecatedList` leaks `method_name` variable
Jason R. Coombs added the comment: Thanks Nikita for the report. I agree, it's inelegant that this property leaks. Because this code is synced with importlib_metadata, I'm not sure it's worth the effort of changing it here. Your change here implies a cherry-pick to the backport and updating its changelog there too. I'd be more inclined to accept a change like this on importlib_metadata, which has a faster iteration and whose changes get naturally incorporated into CPython periodically. What's the harm in leaving this attribute on a class that is itself standing in for deprecated behavior and slated for removal? -- ___ Python tracker <https://bugs.python.org/issue46546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Change by Jason R. Coombs : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Jason R. Coombs added the comment: New changeset 1514d1252f96e6a83eb65c439522a6b5443f6a1a by Jason R. Coombs in branch '3.9': [3.9] bpo-46474: Avoid REDoS in EntryPoint.pattern (sync with importlib_metadata 4.10.1) (GH-30803). (GH-30828) https://github.com/python/cpython/commit/1514d1252f96e6a83eb65c439522a6b5443f6a1a -- ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Jason R. Coombs added the comment: New changeset a7a4ca4f06c8c31d7f403113702ad2e80bfc326b by Jason R. Coombs in branch '3.10': [3.10] bpo-46474: Avoid REDoS in EntryPoint.pattern (sync with importlib_metadata 4.10.1) (GH-30803) (GH-30827) https://github.com/python/cpython/commit/a7a4ca4f06c8c31d7f403113702ad2e80bfc326b -- ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Change by Jason R. Coombs : -- pull_requests: +29016 pull_request: https://github.com/python/cpython/pull/30829 ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Change by Jason R. Coombs : -- pull_requests: +29015 pull_request: https://github.com/python/cpython/pull/30828 ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Change by Jason R. Coombs : -- pull_requests: +29014 pull_request: https://github.com/python/cpython/pull/30827 ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Jason R. Coombs added the comment: New changeset 51c3e28c8a163e58dc753765e3cc51d5a717e70d by Jason R. Coombs in branch 'main': bpo-46474: Avoid REDoS in EntryPoint.pattern (sync with importlib_metadata 4.10.1) (GH-30803) https://github.com/python/cpython/commit/51c3e28c8a163e58dc753765e3cc51d5a717e70d -- ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Jason R. Coombs added the comment: New changeset 443dec6c9a104386ee90165d32fb28d0c5d29043 by Jason R. Coombs in branch 'main': bpo-46474: Apply changes from importlib_metadata 4.10.0 (GH-30802) https://github.com/python/cpython/commit/443dec6c9a104386ee90165d32fb28d0c5d29043 -- ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46425] Multiple test modules fail to run if invoked directly
Jason R. Coombs added the comment: New changeset d888ff5381594641126065e78dc9210dae4436a4 by Jason R. Coombs in branch 'main': bpo-46425: Partially revert "bpo-46425: fix direct invocation of `test_importlib` (GH-30682)" (GH-30799) https://github.com/python/cpython/commit/d888ff5381594641126065e78dc9210dae4436a4 -- ___ Python tracker <https://bugs.python.org/issue46425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41682] [Windows] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure
Change by Jason R. Coombs : -- stage: patch review -> needs patch ___ Python tracker <https://bugs.python.org/issue41682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Change by Jason R. Coombs : -- pull_requests: +28989 pull_request: https://github.com/python/cpython/pull/30803 ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46425] Multiple test modules fail to run if invoked directly
Change by Jason R. Coombs : -- pull_requests: +28990 pull_request: https://github.com/python/cpython/pull/30803 ___ Python tracker <https://bugs.python.org/issue46425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46425] Multiple test modules fail to run if invoked directly
Change by Jason R. Coombs : -- pull_requests: +28988 pull_request: https://github.com/python/cpython/pull/30802 ___ Python tracker <https://bugs.python.org/issue46425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Change by Jason R. Coombs : -- keywords: +patch pull_requests: +28987 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30802 ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
Jason R. Coombs added the comment: Because I want this security issue to be back-portable to older Pythons, I'll first apply importlib_metadata 4.10.0 and then apply the change from 4.10.1 separately. -- ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46474] Inefficient regular expression complexity in EntryPoint.pattern
New submission from Jason R. Coombs : Originally reported to the Python Security Response Team, the EntryPoint.pattern demonstrates a potential [ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_). The issue has been patched and fix released with importlib_metadata 4.10.1. Let's get that fix incorporated into Python as well. -- assignee: jaraco components: Library (Lib) messages: 411282 nosy: jaraco priority: normal severity: normal status: open title: Inefficient regular expression complexity in EntryPoint.pattern type: security versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46425] Multiple test modules fail to run if invoked directly
Change by Jason R. Coombs : -- pull_requests: +28984 pull_request: https://github.com/python/cpython/pull/30799 ___ Python tracker <https://bugs.python.org/issue46425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Change by Jason R. Coombs : -- assignee: -> jaraco ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: I've merged the fix for regrtest and I'll explore Terry's concerns and see what I can devise for those concerns as well. -- ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46425] Multiple test modules fail to run if invoked directly
Change by Jason R. Coombs : -- nosy: +jaraco ___ Python tracker <https://bugs.python.org/issue46425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46124] Deprecation warning in zoneinfo module
Jason R. Coombs added the comment: Closing, presumed fixed. Please re-open if not. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46304] Unable to iterate over lines in a file without a block of code
Jason R. Coombs added the comment: Nice reference. Indeed, the [rationale](https://www.python.org/dev/peps/pep-0533/#id15) of that pep gives a similar example and the [background](https://www.python.org/dev/peps/pep-0533/#id3) describes the problem with the solution I've drafted above (it still depends on garbage collection to close the file). I guess that means that in general, it's not possible to accomplish what I'd like. As author of the PEP, I'm looping in njs. -- nosy: +njs ___ Python tracker <https://bugs.python.org/issue46304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46304] Unable to iterate over lines in a file without a block of code
Jason R. Coombs added the comment: Hi Eric. I did mention that option in my report, but that option requires loading the whole file into memory. I'd like something equivalent to the iterator that `open()` provides, which yields lines lazily. Serihy, thanks for the feedback. I do indeed not want to rely on the implicit closing of the file handle. I'd instead like a helper function/method that will close the file after the iterator is consumed. Something like: def read_lines(path): with path.open() as strm: yield from strm What I'm seeking is for that block to be placed somewhere in the stdlib so that I don't have to copy it into every project that needs/wants this behavior. -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue46304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46304] Unable to iterate over lines in a file without a block of code
New submission from Jason R. Coombs :
I'd like to be able to do something pretty fundamental: lazily load lines from
a file in a single expression.
Best I can tell, that's not possible in the language without triggering
warnings.
One can use 'open' but that triggers a ResourceWarning:
```
$ $PYTHONWARNINGS='error' python -c "lines = open('/dev/null'); tuple(lines)"
Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True>
ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r'
encoding='UTF-8'>
```
One can use a `with` statement, but that requires a block of code and can't be
written easily in a single expression. One can use
`pathlib.Path.read_text().splitlines()`, but that loads the whole file into
memory.
This issue affected the pip-run project, which required 5 new lines in order to
make such an expression possible
(https://github.com/jaraco/pip-run/commit/e2f395d8814539e1da467ac09295922d8ccaf14d).
Can the standard library supply a function or method that would provide this
behavior?
--
components: Library (Lib)
messages: 410075
nosy: jaraco
priority: normal
severity: normal
status: open
title: Unable to iterate over lines in a file without a block of code
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46304>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43976] Allow Python distributors to add custom site install schemes
Jason R. Coombs added the comment: I don't have a good answer, but given the title of this issue (which is specifically scoped to site install schemes), I'm tempted to say we should deal with prefixes in a separate, perhaps broader issue, and there address the reported issue (that a user's prefix override isn't honored by the scheme) and maybe more broadly the issue that there's not a design/spec for python installations (and probably there should be). -- ___ Python tracker <https://bugs.python.org/issue43976> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46246] importlib.metadata.DeprecatedList appears to be missing __slots__
Jason R. Coombs added the comment: Today I learned something. Thanks Arie. Yes, I agree that's a mistake. Perhaps the test suite should also have a test to capture the missed expectation (that __dict__ should not be present or setting attributes on EntryPoints instances should fail). -- ___ Python tracker <https://bugs.python.org/issue46246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46246] importlib.metadata.DeprecatedList appears to be missing __slots__
Jason R. Coombs added the comment: Perhaps it is a mistake. The `__slots__` were added as a (possible premature) optimization in [this conversation](https://github.com/python/importlib_metadata/pull/278/files#r565475347). It's not obvious to me what the danger is in defining __slots__ in a child class but not in a parent. Can you point me to resources or examples that help me understand the concern or missed expectation? The primary motivation behind defining slots is to help ensure immutability. Does the lack of slots violate that expectation? Convince me of the value of fixing this concern and please feel free to proceed with a PR. -- ___ Python tracker <https://bugs.python.org/issue46246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45649] Add tarinfo.Path
Jason R. Coombs added the comment: I'd recommend not to block on issue24132. It's not obvious to me that subclassing would be valuable. It depends on how it's implemented, but in my experience, zipfile.Path doesn't and cannot implement the full interface of pathlib.Path. Instead zipfile.Path attempts to implement a protocol. At the time, the protocol was undefined, but now there exists importlib.resources.abc.Traversable (https://docs.python.org/3/library/importlib.html#importlib.abc.Traversable), the interface needed by importlib.resources. I'd honestly just create a standalone class, see if it can implement Traversable, and only then consider if it should implement a more complicated interface (such as something with symlink support or perhaps even later subclassing from pathlib.Path). -- ___ Python tracker <https://bugs.python.org/issue45649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: > > I presume I don't need to explain why docstrings are nice and preferable > > over comments. > Actually, can you? I searched around and didn't find any good treatise or thorough overview of reasons _why_ docstrings should be preferred, so I performed an internal deconstruction of my motivations and published [this article](https://blog.jaraco.com/why-docstrings-are-preferable-to-comments/) on my blog. -- ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Change by Jason R. Coombs : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46109] Separate resources docs from other importlib docs
Change by Jason R. Coombs : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Jason R. Coombs added the comment: New changeset 35628e4cde71e54afe12aea50c74069afe2c3389 by Jason R. Coombs in branch 'main': bpo-46118: Make sure importlib.resources is included. (GH-30311) https://github.com/python/cpython/commit/35628e4cde71e54afe12aea50c74069afe2c3389 -- ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37043] Buildbots fail when new files are added
Jason R. Coombs added the comment: I encountered this issue again today in issue46118. I started looking into creating the patchcheck, but I realize it may be a little tricky to detect the introduction of a new folder, because `git diff` doesn't actually report new folders, and my initial research indicates it's [far from straightforward](https://stackoverflow.com/a/36293191/70170). I thought maybe git diff --dirstat might help, but it doesn't. It reports 100% different for a new file in a new folder and same for a new file in an existing folder. -- ___ Python tracker <https://bugs.python.org/issue37043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Jason R. Coombs added the comment: And the underlying cause is reported in issue37043. -- ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Jason R. Coombs added the comment: Looks like I encountered the same foot gun when originally introducing the importlib.metadata package (issue34632). -- stage: patch review -> resolved ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Change by Jason R. Coombs : -- pull_requests: +28525 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/30311 ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Jason R. Coombs added the comment: Installed buildbots are failing (like this one: https://buildbot.python.org/all/#/builders/350/builds/1164). I'm going to see if it's a simple fix like updating the makefile or if a rollback is called for. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46109] Separate resources docs from other importlib docs
Jason R. Coombs added the comment: New changeset 99945c6b5cf280bd90075cffae942af44941abcc by Jason R. Coombs in branch 'main': bpo-46109: Separate out files relating to importlib.resources (GH-30160) https://github.com/python/cpython/commit/99945c6b5cf280bd90075cffae942af44941abcc -- ___ Python tracker <https://bugs.python.org/issue46109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Change by Jason R. Coombs : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Jason R. Coombs added the comment: New changeset e712a5b277866a71c195f38c1b5d87d9126dba3e by Jason R. Coombs in branch 'main': bpo-46118: Move importlib.resources to its own package. (#30176) https://github.com/python/cpython/commit/e712a5b277866a71c195f38c1b5d87d9126dba3e -- ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46124] Deprecation warning in zoneinfo module
Jason R. Coombs added the comment: Normalize_path from legacy implementation: https://github.com/python/importlib_resources/blob/3beb2fd5831e65f7b45033e1ec276c4a6b4ca973/importlib_resources/_legacy.py#L30-L40 -- ___ Python tracker <https://bugs.python.org/issue46124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46124] Deprecation warning in zoneinfo module
Jason R. Coombs added the comment: > Does `joinpath` have less validation? Yes. Previously, resources.* would perform some validation on the path to ensure that it didn't contain path separators (to avoid users attempting to get resources in subdirectories or perhaps manipulating the path in other ways). So no, they're not equivalent. If `resource_name` or "zones" ever contained path separators, the former implementation would raise an error whereas this implementation would attempt to join those characters to the path. Since "zones" is a static string, it's clearly not affected. And `resource_name` can't have posixpath.sep. If `key` had an ntpath.sep, that might behave differently, but that seemed like an edge case not worth exploring. If it is worth exploring, I would recommend not to use normalize_path, but instead to implement the validation in zoneinfo._common. That is, wrap key in `_validate_key()` that protects against invalid paths. But in practice, it's better to do that closer to where the unsanitized data would be encountered (if at all). -- ___ Python tracker <https://bugs.python.org/issue46124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46109] Separate resources docs from other importlib docs
Jason R. Coombs added the comment: I realize, I can limit the scope of this issue to address 'resources' alone, leaving ABCs where they are except for resource-related ones, allowing us to defer a larger refactoring to a separate issue/effort. -- title: Separate resources and abc docs from other importlib docs -> Separate resources docs from other importlib docs ___ Python tracker <https://bugs.python.org/issue46109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46118] Migrate importlib.resources into a package
Jason R. Coombs added the comment: I recently noticed that some docs already refer to `importlib.resources.abc` even though it doesn't currently exist (https://github.com/python/cpython/blame/main/Doc/library/importlib.rst#L948). That finding leads me to adjust my expectation that perhaps exposing those classes from that module would be preferable (since that was the expectation from the start). -- ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46109] Separate resources and abc docs from other importlib docs
Jason R. Coombs added the comment: As I'm exploring this issue, I notice that currently, the docs refer to :class:`importlib.resources.abc.Traversable` (even though that doesn't currently exist) (https://github.com/python/cpython/blame/main/Doc/library/importlib.rst#L948). -- ___ Python tracker <https://bugs.python.org/issue46109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46109] Separate resources and abc docs from other importlib docs
Jason R. Coombs added the comment: > a ToC at the top of the main page which identifies the submodules (and > provides a brief summary for each) would be extra helpful. I've added this in the latest commit (1adefaf552). -- ___ Python tracker <https://bugs.python.org/issue46109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46109] Separate resources and abc docs from other importlib docs
Jason R. Coombs added the comment: The reason I wanted to consider issue46118 first was because I wanted to explore whether the ABCs from `importlib_resources.abc` should be _documented_ as `importlib.resources.abc` or `importlib.abc` (as they are now). After filing the issue and exploring the concerns (namely, should users be directed _away_ from `importlib.abc` for these classes), I'm uncertain whether it's worth the effort to make that transition, and certainly not in haste, so this effort can proceed to document the status quo (ABCs presented primarily in `importlib.abc`). -- ___ Python tracker <https://bugs.python.org/issue46109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46124] Deprecation warning in zoneinfo module
Change by Jason R. Coombs : -- assignee: jaraco -> p-ganssle ___ Python tracker <https://bugs.python.org/issue46124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Change by Jason R. Coombs : -- keywords: +patch pull_requests: +28415 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30194 ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: After some investigation (and tracing calls through a dozen or more layers), I found that Python's own regression tests can disable this behavior thus: ``` diff --git a/Lib/test/support/testresult.py b/Lib/test/support/testresult.py index 2cd1366cd8..328ca8760e 100644 --- a/Lib/test/support/testresult.py +++ b/Lib/test/support/testresult.py @@ -145,7 +145,8 @@ def get_test_runner_class(verbosity, buffer=False): return functools.partial(unittest.TextTestRunner, resultclass=RegressionTestResult, buffer=buffer, - verbosity=verbosity) + verbosity=verbosity, + descriptions=False,) return functools.partial(QuietRegressionTestRunner, buffer=buffer) def get_test_runner(stream, verbosity, capture_output=False): ``` Combined with the above diff (with a docstring), the output is now as desired: ``` $ ./python.exe -m test -v test_importlib | grep '... ERROR' test_entry_points_unique_packages (test.test_importlib.test_metadata_api.APITests) ... ERROR test test_importlib failed ``` It seems it would be wise to enable this setting by default, given that without it, every test module is forced to replace docstrings with comments. -- ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: It looks like that 'descriptions' attribute is passed through from TextTestRunner, which sets it to True by default (https://github.com/python/cpython/blob/9b52920173735ac609664c6a3a3021d24a95a092/Lib/unittest/runner.py#L163). It seems that behavior isn't controllable through any command-line options or environment variables. -- ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: Looks like the code, I believe here's where the reporting happens: https://github.com/python/cpython/blob/9b52920173735ac609664c6a3a3021d24a95a092/Lib/unittest/runner.py#L48-L51 I see a "description" property there that may already provide the feature. -- ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: My guess is the tests were run with something like this: ``` ./python.exe -E -We -m test -v test_importlib | grep '... ERROR' Entry points should only be exposed for the first package ... ERROR test test_importlib failed ``` In that case, the location of the test is replaced with the first line of the docstring. If there's no docstring, however, the location of the failure is easier to detect: ``` $ ./python.exe -E -We -m test -v test_importlib | grep '... ERROR' test_entry_points_unique_packages (test.test_importlib.test_metadata_api.APITests) ... ERROR test test_importlib failed ``` -- ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment:
I created this diff:
```diff
diff --git a/Lib/test/test_importlib/test_metadata_api.py
b/Lib/test/test_importlib/test_metadata_api.py
index e16773a7e8..92aacd5ad5 100644
--- a/Lib/test/test_importlib/test_metadata_api.py
+++ b/Lib/test/test_importlib/test_metadata_api.py
@@ -90,8 +90,11 @@ def test_entry_points_distribution(self):
self.assertEqual(ep.dist.version, "1.0.0")
def test_entry_points_unique_packages(self):
-# Entry points should only be exposed for the first package
-# on sys.path with a given name.
+"""
+Entry points should only be exposed for the first package
+on sys.path with a given name.
+"""
+raise ValueError("Failing on purpose")
alt_site_dir = self.fixtures.enter_context(fixtures.tempdir())
self.fixtures.enter_context(self.add_sys_path(alt_site_dir))
alt_pkg = {
```
And then ran the tests, but the output is easy to totally scrutable:
```
cpython bpo-46126/bad-error-message $ ./python.exe -m test.test_importlib
sE.x..
sTrying
20 threads ... 44.7 ms OK.
Trying 50 threads ... 36.8 ms OK.
Trying 20 threads ... 27.7 ms OK.
Trying 50 threads ... 28.0 ms OK.
Trying 20 threads ... 27.9 ms OK.
Trying 50 threads ... 31.1 ms OK.
.Trying 20 threads ... 7.1 ms OK.
Trying 50 threads ... 7.6 ms OK.
Trying 20 threads ... 3.2 ms OK.
Trying 50 threads ... 8.5 ms OK.
Trying 20 threads ... 3.4 ms OK.
Trying 50 threads ... 8.7 ms OK.
.Trying 20 threads ... 40.3 ms OK.
Trying 50 threads ... 8.7 ms OK.
Trying 20 threads ... 3.5 ms OK.
Trying 50 threads ... 6.5 ms OK.
Trying 20 threads ... 3.2 ms OK.
Trying 50 threads ... 6.5 ms OK.
..ssss...
==
ERROR: test_entry_points_unique_packages
(test.test_importlib.test_metadata_api.APITests)
Entry points should only be exposed for the first package
--
Traceback (most recent call last):
File
"/Users/jaraco/code/public/cpython/Lib/test/test_importlib/test_metadata_api.py",
line 97, in test_entry_points_unique_packages
raise ValueError("Failing on purpose")
^^
ValueError: Failing on purpose
--
Ran 1426 tests in 2.377s
FAILED (errors=1, skipped=6, expected failures=1)
```
So there must be some other test invocation that doesn't provide the clarity of
which test is failing.
--
___
Python tracker
<https://bugs.python.org/issue46126>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46126] Unittest output drives developers to avoid docstrings
Jason R. Coombs added the comment: Absolutely. I was thinking to do just that. -- ___ Python tracker <https://bugs.python.org/issue46126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46125] Test the preferred API instead of relying on legacy for coverage
Jason R. Coombs added the comment: New changeset 9b52920173735ac609664c6a3a3021d24a95a092 by Jason R. Coombs in branch 'main': bpo-46125: Refactor tests to test traversable API directly. Includes changes from importlib_resources 5.4.0. (GH-30189) https://github.com/python/cpython/commit/9b52920173735ac609664c6a3a3021d24a95a092 -- ___ Python tracker <https://bugs.python.org/issue46125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46124] Deprecation warning in zoneinfo module
Change by Jason R. Coombs : -- keywords: +patch pull_requests: +28410 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30190 ___ Python tracker <https://bugs.python.org/issue46124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
