New submission from Jason R. Coombs :
Attempting to build Python on macOS following [the
instructions](https://devguide.python.org/setup/#macos-and-os-x) (for Homebrew).
xz is installed:
```
$ brew --prefix xz
Change by Jason R. Coombs :
--
components: +macOS
nosy: +ned.deily, ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue40840>
___
___
Python-bug
Change by Jason R. Coombs :
--
pull_requests: +19816
pull_request: https://github.com/python/cpython/pull/20576
___
Python tracker
<https://bugs.python.org/issue39
Jason R. Coombs added the comment:
What do you think about readlink returning something like:
class Link(str):
print_name = None # type: str | None
@property
def friendly_name(self) -> str:
return self.print_name or self
os.readlink would always return one of these Link obje
Jason R. Coombs added the comment:
New changeset 5c1d745da5e1166a8724b619060165dcf3949e93 by Miss Islington (bot)
in branch '3.8':
bpo-39830: Add zipfile.Path to __all__ (GH-19115) (GH-19116)
https://github.com/python/cpython/commit/5c1d745da5e1166a8724b619060165
Jason R. Coombs added the comment:
Thanks Steve. While I was able to avoid the original symptom by not using
readlink, I still think there's an issue here, both in the surprising behavior
observed by shutil.copyfile, but also by the essential behavior of readlink.
The more essential
Jason R. Coombs added the comment:
Good news is it looks like the issue with setuptools_scm can be address in a
relatively straightforward manner
(https://github.com/pypa/setuptools_scm/issues/436#issuecomment-632899446).
I think that means the answers to the above questions are
Jason R. Coombs added the comment:
To make matters more complicated, `git rev-parse --show-toplevel` also returns
the realpath:
```
# git rev-parse --show-toplevel
//vmware-host/Shared Folders/home/code/main/path
```
--
___
Python tracker
<ht
Jason R. Coombs added the comment:
It's because on Unix:
```
>>> os.path.relpath('/Users/jaraco/code/main/path/.flake8', '')
'.flake8'
```
But on Windows, relpath raises an error for the comparable call:
```
>>> os.path.relpath('\\
Jason R. Coombs added the comment:
It seems the underlying reason the behavior fails is the (intended) difference
resolving the empty path to a realpath when a symlink points to another volume.
The failing routine invokes realpath early
(https://github.com/pypa/setuptools_scm/blob
Change by Jason R. Coombs :
--
nosy: +eryksun
___
Python tracker
<https://bugs.python.org/issue40732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
> Perhaps related...
Now I'm thinking the issue is different, so I've created issue40732 to track
the realpath issue.
--
___
Python tracker
<https://bugs.pytho
New submission from Jason R. Coombs :
I've encountered an apparent regression on Python 3.8 on Windows when the
current working directory is in a symlink to another volume and one runs
`setup.py develop` on a project using setuptools_scm
(https://github.com/pypa/setuptools_scm/issue
Jason R. Coombs added the comment:
> I'll see if `realpath` satisfies the test suite needs for path pie.
I've tried replacing `readlink` with `realpath` and the tests still pass on
Unix-like OSs, and also passes on Python 3.8 on Windows, but now fails on older
Pythons on Windo
Jason R. Coombs added the comment:
Perhaps related, I've encountered another apparent regression on Python 3.8 on
Windows when the current working directory is in a symlink to another volume
and one runs `setup.py develop` on a project using setuptools_scm
(https://github.com
Jason R. Coombs added the comment:
> Unless you're specifically testing single steps through symlink chains, you
> probably want to just use realpath anyway.
I do see now the references to `realpath` in the docs... and I think that
satisfies the need I described above. It doesn
Jason R. Coombs added the comment:
> Changing readlink to always return the correct path was deliberate.
Understood. However, this statement assumes the "correct path" is the most
precise path to resolve the target. If you instead define "correct path" as the
one that
Jason R. Coombs added the comment:
> This is only an issue for broken symlinks, right? (More precisely, those that
> cannot be resolved, which may include very long paths on some machines.)
Unfortunately, no. In the original post above, you can see temp/bar points to
C:\Users\jarac
Jason R. Coombs added the comment:
I strongly suspect bpo-37834 and GH-15231 is where the difference was
introduced.
--
___
Python tracker
<https://bugs.python.org/issue40
Jason R. Coombs added the comment:
Thank you Eryk for the thorough and informative investigation. Seriously, wow.
> Do you want 3.8 to revert to using the print name, at least for symlinks?
> (ntpath._readlink_deep would need to be modified to support long target
> paths.) Or
New submission from Jason R. Coombs :
In https://github.com/jaraco/path/issues/186, the Path project discovered a
regression with Python 3.8. It seems that if one creates a symlink with an
absolute path. I used `shutil.copytree('temp', 'temp2', True)` and it p
Jason R. Coombs added the comment:
> I thought it might be useful for testing purposes if os.path (i.e. ntpath and
> posixpath) had a way to set the home directory that it uses in way that
> wouldn't affect other libraries and child processes.
I was thinking about this, and
Jason R. Coombs added the comment:
> Platform differences can be papered over with functions.
I’m not suggesting that from within Python there should be another way to
detect a home directory. The expanduser functionality as written is just fine
for that, though I agree with Steve that us
Jason R. Coombs added the comment:
I addressed the [setuptools test suite
issue](https://github.com/pypa/setuptools/issues/2112) with [this
commit](https://github.com/pypa/setuptools/commit/f866311d60f54499c3637309e3429780d8c8f218).
What was a one-line elegant solution is now multiple lines
Jason R. Coombs added the comment:
I should also point out that this was a documented feature of Python that was
removed without any deprecation period.
--
___
Python tracker
<https://bugs.python.org/issue36
Jason R. Coombs added the comment:
Today I ran into an issue due to this change. I have a test that sets
`os.environ['HOME']` in order to ensure that `os.path.expanduser(~)` returns
that value
(https://github.com/pypa/setuptools/blob/f6f25adfc81df76e186bf6c3738a1baa0f92be05/setupt
Jason R. Coombs added the comment:
My bad. I probably could have been more proactive about providing a reproducer.
The problem, as described above (msg335220) and in the associated cmdix ticket,
is that invocation of `platform.(anything)` causes shelling out to execute
"uname", s
Jason R. Coombs added the comment:
In issue40570, Marc-Andre writes:
> I don't think that deprecating standard tuple access is an option
for the uname() return value, since it's documented to be a tuple.
My thinking here is that as part of the deprecation, the documentation woul
Jason R. Coombs added the comment:
> you added a late binding optimization for the whole uname return
tuple to save the effort of ... shell access.
It wasn't to save the effort and it wasn't an optimization. There was a
fundamental race condition where it became impossible t
Jason R. Coombs added the comment:
In https://github.com/jaraco/cpython/tree/bc73729eb9, I started drafting a
proposed implementation to address this concern, but ran into a snag - the
tests immediately reveal that `tuple(platform.uname())` invokes `__len__`,
triggering the deprecation
Jason R. Coombs added the comment:
I've gone ahead and merged PR 20015 to fix the issue, but I'm happy to revisit
if a better approach is proposed.
--
keywords: +3.9regression -patch
resolution: -> fixed
stage: patch review -> resolved
status
Jason R. Coombs added the comment:
New changeset 2c3d508c5fabe40dac848fb9ae558069f0576879 by Jason R. Coombs in
branch 'master':
bpo-40570: Improve compatibility of uname_result with late-bound .platform
(#20015)
https://github.com/python/cpyt
Jason R. Coombs added the comment:
Thanks Marc-Andre for the suggestion, but I don't think that approach is viable
here. The whole point of issue35967 was to defer the execution of the
`.processor` behavior until it was requested. The intention is not to extend
the tuple, but to short
New submission from Jason R. Coombs :
In issue40570, I learned that some users are still relying on legacy tuple-like
behaviors of `platform.uname()`, namely the access by item position and length:
```
platform.uname()[0]
len(platform.uname())
```
I propose to deprecate these behaviors and
Jason R. Coombs added the comment:
Thanks David for the report and the draft PR (which helped me validate my
thinking on the matter). In PR 20015, I've included additional tests. I've also
re-written the compatibility functions to rely on the main `__iter__` override.
Another
Jason R. Coombs added the comment:
I've merged PR 19722. Some follow up actions I'd like to do:
- Add hooks for `.files()` on built-in loaders.
- Replace `loader.get_resource_reader()` with adapters around `.files()` for
built-
Change by Jason R. Coombs :
--
pull_requests: +19326
pull_request: https://github.com/python/cpython/pull/20015
___
Python tracker
<https://bugs.python.org/issue40
Jason R. Coombs added the comment:
If it is important to retain the `len`, it's probably also important to retain
the `[-N]` accesses and possibly other behaviors of a length 6 tuple.
--
___
Python tracker
<https://bugs.python.org/is
Jason R. Coombs added the comment:
It was intentional to address issue35967, although it was meant to remain
compatible.
Is len(uname()) an important behavior to retain? It feels like an
implementation detail to me.
--
___
Python tracker
<ht
Jason R. Coombs added the comment:
New changeset 7f7e706d78ab968a1221c6179dfdba714860bd12 by Jason R. Coombs in
branch 'master':
bpo-39791: Add files() to importlib.resources (GH-19722)
https://github.com/python/cpython/commit/7f7e706d78ab968a1221c6179dfdba
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +19044
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19722
___
Python tracker
<https://bugs.python.org/issu
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:
New changeset 518835f3354d6672e61c9f52348c1e4a2533ea00 by Jason R. Coombs in
branch 'master':
bpo-35967 resolve platform.processor late (GH-12239)
https://github.com/python/cpython/commit/518835f3354d6672e61c9f52348c1e
Jason R. Coombs added the comment:
New changeset e72cbcb346cfcc1ed7741ed6baf1929764e1ee74 by Jason R. Coombs in
branch 'master':
bpo-35967: Make test_platform.test_uname_processor more lenient to satisfy
build bots. (GH-19544)
https://github.com/python/cpyt
Jason R. Coombs added the comment:
I'm hoping that PR 19544 fixes the issue.
--
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Pytho
Change by Jason R. Coombs :
--
pull_requests: +18891
pull_request: https://github.com/python/cpython/pull/19544
___
Python tracker
<https://bugs.python.org/issue35
Jason R. Coombs added the comment:
The aformentioned test broke tests in buildbots:
https://buildbot.python.org/all/#builders/105/builds/779
--
___
Python tracker
<https://bugs.python.org/issue35
Change by Jason R. Coombs :
--
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Python-bugs-list mailin
Jason R. Coombs added the comment:
In the 3.8 backport, I retained API compatibility and backported only the
performance improvement code.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracke
Jason R. Coombs added the comment:
New changeset 3e72de9e08b03a15875f5b226c5f096e567dab42 by Miss Islington (bot)
in branch '3.8':
[3.8] bpo-39667: Sync zipp 3.0 (GH-18540) (GH-18701)
https://github.com/python/cpython/commit/3e72de9e08b03a15875f5b226c5f09
Jason R. Coombs added the comment:
New changeset 4b4e90a51848578dc06341777a929a0be4f4757f by Jason R. Coombs in
branch 'master':
bpo-35967: Baseline values for uname -p (GH-12824)
https://github.com/python/cpython/commit/4b4e90a51848578dc06341777a929a
Jason R. Coombs added the comment:
Thanks for the report and the fix.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
New changeset 15e5024d04fc89d948ae761d88048bc58a56b650 by Roman Yurchak in
branch 'master':
bpo-40029 mark test_importlib.test_zip as requiring zlib (#19105)
https://github.com/python/cpython/commit/15e5024d04fc89d948ae761d88048bc58a56b650
-
Jason R. Coombs added the comment:
New changeset 9a81ab107a54b8ca320fb703f7c68e14ccd9d016 by Zackery Spytz in
branch 'master':
bpo-39830: Add zipfile.Path to __all__ (GH-19115)
https://github.com/python/cpython/commit/9a81ab107a54b8ca320fb703f7c68e
Jason R. Coombs added the comment:
I've filed [Homebrew/brew#7204](https://github.com/Homebrew/brew/issues/7204)
to track the testing/validation of this change against Homebrew.
--
___
Python tracker
<https://bugs.python.org/is
Change by Jason R. Coombs :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue22490>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
New changeset 5765acaf64cc2c52ce8a35de9407faddf6885598 by Jason R. Coombs in
branch '3.7':
[3.7] bpo-22490: Remove __PYVENV_LAUNCHER__ from environment during launch
(GH-9516) (GH-19111)
https://github.com/python/cpyt
Jason R. Coombs added the comment:
New changeset c959fa9353b92ce95dd7fe3f25fe65bacbe22338 by Miss Islington (bot)
in branch '3.8':
bpo-22490: Remove __PYVENV_LAUNCHER__ from environment during launch (GH-9516)
(GH-19110)
https://github.com/python/cpyt
Change by Jason R. Coombs :
--
pull_requests: +18472
pull_request: https://github.com/python/cpython/pull/19111
___
Python tracker
<https://bugs.python.org/issue22
Jason R. Coombs added the comment:
New changeset 044cf94f610e831464a69a8e713dad89878824ce by Ronald Oussoren in
branch 'master':
bpo-22490: Remove __PYVENV_LAUNCHER__ from environment during launch (GH-9516)
https://github.com/python/cpython/commit/044cf94f610e831464a69a8e713dad
Jason R. Coombs added the comment:
How's that for service ;)
Glad to hear it worked. I'm going to close this as won't fix (as it was
reported against 3.7 and 3.8 and changing it for them would be
backward-incompatible, even if more correct). Please report back if t
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:
I believe this issue was addressed in the latest importlib_resources. If so,
that behavior is being ported to Python 3.9 in issue39791. Would you test with
`importlib_resources` 1.1 or later and see if that suits your purposes? If so,
please use
Jason R. Coombs added the comment:
The latest release, 1.3.0, includes extensibility support and has been merged
with the cpython branch of the importlib_resources project. I believe that code
is now synced with this project and ready to be applied here. I'm hoping
benthayer can appl
Jason R. Coombs added the comment:
New changeset 0aeab5c4381f0cc11479362af2533b3a391312ac by Jason R. Coombs in
branch 'master':
bpo-39667: Sync zipp 3.0 (GH-18540)
https://github.com/python/cpython/commit/0aeab5c4381f0cc11479362af2533b
Change by Jason R. Coombs :
--
assignee: -> jaraco
components: +Library (Lib)
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue39791>
___
__
New submission from Jason R. Coombs :
In the [importlib_resources
backport](https://gitlab.com/python-devs/importlib_resources/)... in particular
in [issue 58](https://gitlab.com/python-devs/importlib_resources/issues/58) and
[merge request
76](https://gitlab.com/python-devs
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +17917
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18540
___
Python tracker
<https://bugs.python.org/issu
New submission from Jason R. Coombs :
zipp 3.0 includes enhanced support for the .open() method as well as
performance improvements in 2.2.1
(https://zipp.readthedocs.io/en/latest/history.html).
--
components: Library (Lib)
messages: 362158
nosy: jaraco
priority: normal
severity
Change by Jason R. Coombs :
--
title: Update zipfile.Path with zipfile 3.0 -> Update zipfile.Path with zipp 3.0
___
Python tracker
<https://bugs.python.org/issu
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:
New changeset ed4d263e8767b0e4c47df99141b500d36ce0275d by Miss Islington (bot)
in branch '3.8':
bpo-39595: Improve zipfile.Path performance (GH-18406) (GH-18472)
https://github.com/python/cpython/commit/ed4d263e8767b0e4c47df99141b500
Jason R. Coombs added the comment:
New changeset e5bd73632e77dc5ab0cab77e48e94ca5e354be8a by Jason R. Coombs in
branch 'master':
bpo-39595: Improve zipfile.Path performance (#18406)
https://github.com/python/cpython/commit/e5bd73632e77dc5ab0cab77e48e94c
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +17802
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18406
___
Python tracker
<https://bugs.python.org/issu
Change by Jason R. Coombs :
--
assignee: -> jaraco
___
Python tracker
<https://bugs.python.org/issue39595>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Jason R. Coombs :
As reported in [jaraco/zipp#32](https://github.com/jaraco/zipp/issues/32),
performance of zipfile.Path is inadequate. This bug tracks the incorporation of
those improvements as well as those in [importlib_metadata
1.5](https://importlib
Jason R. Coombs added the comment:
Given that this issue only affects those who upgraded from beta versions, I'm
inclined to say it shouldn't be part of the installer, and that the long tail
of users affected probably can track it down here.
I don't feel strongly
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:
New changeset 98b1c0c7ac7c80aac8bce8648fe14b55abeb382a by Jason R. Coombs (Miss
Islington (bot)) in branch '3.8':
bpo-39297: Update for importlib_metadata 1.4. (GH-17947) (GH-17952)
https://github.com/python/cpyt
Jason R. Coombs added the comment:
New changeset 136735c1a2efb320e4cbb64b40f1191228745b39 by Jason R. Coombs in
branch 'master':
bpo-39297: Update for importlib_metadata 1.4. (GH-17947)
https://github.com/python/cpython/commit/136735c1a2efb320e4cbb64b40f119
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +17355
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17947
___
Python tracker
<https://bugs.python.org/issu
New submission from Jason R. Coombs :
Importlib_metadata 1.4 adds performance improvements to the distribution
discovery mechanism. Let's incorporate those upstream.
--
components: Library (Lib)
messages: 359773
nosy: jaraco
priority: normal
severity: normal
status: open
Jason R. Coombs added the comment:
In issue39103, I filed a bug relating to this issue.
I'd like for Python to provide a portable implementation of strftime instead of
just documenting that the version isn't portable.
Given that this ticket assigned to 'docs' sugg
Jason R. Coombs added the comment:
In PR 17378, we discussed and I believe the conclusion is that the fix in the
other PR(s) is sufficient to address the deficiency.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Jason R. Coombs added the comment:
New changeset 33cb4a62bf6848093b7a05c9794582d204798b1b by Jason R. Coombs (Miss
Islington (bot)) in branch '3.8':
bpo-38907: Suppress any exception when attempting to set V6ONLY. (GH-17864)
(GH-17865)
https://github.com/python/cpyt
Jason R. Coombs added the comment:
New changeset 7cdc31a14c824000cbe8b487900c9826a33f6940 by Jason R. Coombs in
branch 'master':
bpo-38907: Suppress any exception when attempting to set V6ONLY. (GH-17864)
https://github.com/python/cpython/commit/7cdc31a14c824000cbe8b487900c98
Change by Jason R. Coombs :
--
pull_requests: +17281
pull_request: https://github.com/python/cpython/pull/17864
___
Python tracker
<https://bugs.python.org/issue38
Jason R. Coombs added the comment:
New changeset 5ed9d60bc53e2eb0a88f07d5afe5299acdc0b216 by Jason R. Coombs (Miss
Islington (bot)) in branch '3.8':
bpo-38907: In http.server script, restore binding to IPv4 on Windows.
(GH-17851) (#17854)
https://github.com/python/cpyt
Jason R. Coombs added the comment:
New changeset ee94bdb0598f9bc47d6a49e58fffc97aa617be96 by Jason R. Coombs in
branch 'master':
bpo-38907: In http.server script, restore binding to IPv4 on Windows. (GH-17851)
https://github.com/python/cpython/commit/ee94bdb0598f9bc47d6a49e58fffc9
Jason R. Coombs added the comment:
Other than addressing issue38907, is there anything else to be done here? In
GH-17851, I've proposed a surgical fix to address the issue with IPv4 being
unbound on Windows.
--
___
Python tracker
&
Change by Jason R. Coombs :
--
pull_requests: +17272
pull_request: https://github.com/python/cpython/pull/17851
___
Python tracker
<https://bugs.python.org/issue38
Change by Jason R. Coombs :
--
pull_requests: +17274
pull_request: https://github.com/python/cpython/pull/17851
___
Python tracker
<https://bugs.python.org/issue20
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +17273
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17851
___
Python tracker
<https://bugs.python.org/issu
Jason R. Coombs added the comment:
In issue39211, I've done a good deal of investigation on this issue and
confirmed your findings - on Windows, the server fails to bind dual stack on
Windows, but instead binds IPV6ONLY. That needs to be fixed such that the
default is to bind dual-
Jason R. Coombs added the comment:
Indeed, if I apply this patch:
```
diff --git a/Lib/http/server.py b/Lib/http/server.py
index 47a4fcf9a6..de995ae4b9 100644
--- a/Lib/http/server.py
+++ b/Lib/http/server.py
@@ -1246,6 +1246,11 @@ def test(HandlerClass=BaseHTTPRequestHandler
Jason R. Coombs added the comment:
> It's the addition of flags=socket.AI_PASSIVE on Lib/http/server.py:1233
> that's causing this.
Can you elaborate? What is it causing?
I can see that flag was added in
https://github.com/python/cpython/pu
Jason R. Coombs added the comment:
First, a quick primer in IP:
- Addresses are written as :::::::, but any
single span of zeros can be written as ::, so `::` is all zeros and `::1` is
the same as :::::::0001.
- ::1 is the local
New submission from Jason R. Coombs :
On Python 3.8, there's a difference between how datetime.datetime.strftime
renders %Y for years < 1000 between Linux and other platforms.
# Linux
$ docker run -it python python -c 'import datetime;
print(datetime.date(900,1,1)
Change by Jason R. Coombs :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
501 - 600 of 1490 matches
Mail list logo