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 e1786b54162e2bfb01ca5aafa19d596c4af5a803 by Jason R. Coombs
(Anthony Sottile) in branch 'master':
bpo-36853: Fix suspicious.py to actually print the unused rules (#13579)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
New changeset 102e9b40ff6ee45086a5f0d34d9c60c581a1e5e5 by Jason R. Coombs in
branch 'master':
bpo-38010 Sync importlib.metadata with importlib_metadata 0.20. (GH-15646)
https://github.com/python/cpython/commit/102e9b40ff6ee45086a5f0d34d9c60c581a1e5e5
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +15312
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15646
___
Python tracker
<https://bugs.python.org/issu
New submission from Jason R. Coombs :
Importlib_metadata 0.20 addresses two issues
(https://importlib-metadata.readthedocs.io/en/latest/changelog%20(links).html#id1).
Sync those changes here.
--
components: Library (Lib)
messages: 351004
nosy: jaraco
priority: normal
severity: normal
Jason R. Coombs added the comment:
Thanks very much shireenrao for the PR, which is now merged with Python 3.8+.
I've additionally backported the fix to zipp in 0.6.0.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +P
Jason R. Coombs added the comment:
New changeset c410f381bf66c48d84812e19e3ba7c2878511a3e by Jason R. Coombs (Miss
Islington (bot)) in branch '3.8':
bpo-37772: fix zipfile.Path.iterdir() outputs (GH-15170) (#15461)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
New changeset a4e2991bdc993b60b6457c8a38d6e4a1fc845781 by Jason R. Coombs
(shireenrao) in branch 'master':
bpo-37772: fix zipfile.Path.iterdir() outputs (GH-15170)
https://github.com/python/cpython/commit/a4e2991bdc993b60b6457c8a38d6e4a1fc845781
Jason R. Coombs added the comment:
> Is there a reason that requires() and files() return iterators instead of
> lists?
I'm a huge fan of `itertools` and Python 3's move to prefer iterables over
materialized lists, and I feel that forcing materialized results gives the
caller less c
Change by Jason R. Coombs :
--
assignee: -> jaraco
___
Python tracker
<https://bugs.python.org/issue37772>
___
___
Python-bugs-list mailing list
Unsubscrib
Jason R. Coombs added the comment:
Please do.
--
___
Python tracker
<https://bugs.python.org/issue37772>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
> Why is the code in `Lib/importlib/metadata/__init__.py`
Mainly because originally, the code was in multiple modules. I'm happy for it
to move into a single file module.
--
___
Python tracker
<
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 f96334c17946683dd4fb5a84e86a7a4caa4b487d by Jason R. Coombs (Miss
Islington (bot)) in branch '3.8':
bpo-37697: Sync with importlib_metadata 0.19 (GH-14993) (GH-14995)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
New changeset 049460da9c7b5f51732e2966195c44713af9dc4c by Jason R. Coombs in
branch 'master':
bpo-37697: Sync with importlib_metadata 0.19 (#14993)
https://github.com/python/cpython/commit/049460da9c7b5f51732e2966195c44713af9dc4c
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +14759
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14993
___
Python tracker
<https://bugs.python.org/issu
Jason R. Coombs added the comment:
Okay, I think the issue was that I had failed to `make regen-importlib`. After
doing that, the tests are passing. PR incoming.
--
___
Python tracker
<https://bugs.python.org/issue37
Jason R. Coombs added the comment:
I've started work on this in
https://github.com/jaraco/cpython/commit/ee913fd4b1cc3bb324f43bfebd4f1006f90c2b6e,
but two tests are failing:
==
FAIL: test_egg_info
New submission from Jason R. Coombs :
Importlib_metadata 0.19 is about to release. Let's sync the code with that
milestone (https://gitlab.com/python-devs/importlib_metadata/-/milestones/20).
--
components: Library (Lib)
messages: 348581
nosy: barry, jaraco
priority: normal
severity
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 66905d14672517d50dc8ba516b9839f9ddbcc131 by Jason R. Coombs (Miss
Islington (bot)) in branch '3.8':
bpo-37520: Correct behavior for zipfile.Path.parent (GH-14638) (GH-14641)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
New changeset 38f44b4a4adc37e8f5f8971917d8b3145f351a56 by Jason R. Coombs in
branch 'master':
bpo-37520: Correct behavior for zipfile.Path.parent (GH-14638)
https://github.com/python/cpython/commit/38f44b4a4adc37e8f5f8971917d8b3145f351a56
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +14452
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14638
___
Python tracker
<https://bugs.python.org/issu
New submission from Jason R. Coombs :
Originally reported in https://github.com/jaraco/zipp/issues/7, the parent of a
Path object referencing a directory is returning the incorrect result:
cpython master $ docker run -it python:rc-buster
Jason R. Coombs added the comment:
I see looking at the code and docs now that this work was done for Python 3.8.
--
resolution: -> works for me
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
The missing reference above should be
https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/#iqm9GJhlyWhcM78e.97
--
___
Python tracker
<https://bugs.python.org/issue37
New submission from Jason R. Coombs :
A few years ago, Windows [announced more lenient support for creating symbolic
links](). This more lenient support requires the caller to pass a flag in the
API. Neither the blog post nor the API docs give any indication of why one
would not ever pass
Jason R. Coombs added the comment:
I imagine that importlib.metadata isn’t imported at bootstrap time, only after
the import infrastructure is ready. I think an early failure to import one of
those dependencies is desirable. What is the reasoning behind deferring the
imports and why does
Jason R. Coombs added the comment:
> I've just locally ran sphinx 2.0.0 on 071cbd4ea1 (the current tip of your PR)
> and I'm not getting any error, which one are you getting?
The issue occurs on 2347d3ae36 with `make suspicious` with Sphinx 2.0.0 and
2.0.1.
```
Doc 2347d3ae36
Jason R. Coombs added the comment:
In GH-13565, @yan12125 provides [this
reference](https://github.com/python/buildmaster-config/blob/master/master/custom/factories.py)
to the buildbot code that copies the code and thus imposes the requirement to
declare source directories
Jason R. Coombs added the comment:
I believe buildbots are fixed. Please re-open if you find otherwise.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
New changeset f7fba6cfb62edfc22e9b2e12a00ebaf5f348398e by Jason R. Coombs in
branch 'master':
bpo-34632 fix buildbots and remove artifact (GH-13566)
https://github.com/python/cpython/commit/f7fba6cfb62edfc22e9b2e12a00ebaf5f348398e
Jason R. Coombs added the comment:
> By the way, I think Python.framework is not needed?
Correct. That was an artifact that I unintentionally added.
I've submitted https://github.com/python/cpython/pull/13566 to address the two
concerns.
I've also opened issue37043 and issue37
New submission from Jason R. Coombs :
When developing on macOS, after some build/test operations (I'm not sure
exactly which, but seemingly relating to a framework build), artifacts are
generated which aren't ignored. As a result, it's easy for them to leak into a
merge request as they did
Change by Jason R. Coombs :
--
pull_requests: +13476
pull_request: https://github.com/python/cpython/pull/13566
___
Python tracker
<https://bugs.python.org/issue34
New submission from Jason R. Coombs :
As [reported here](https://bugs.python.org/issue34632#msg343445), I submitted a
pull request that passed all tests locally and in CI, but when accepted, build
bots started to fail as a result of new files having been added to the project.
It seems it's
Jason R. Coombs added the comment:
New changeset c3738cfe63b1f2c1dc4a28d0ff9adb4e9e3aae1f by Jason R. Coombs
(Chih-Hsuan Yen) in branch 'master':
bpo-34632: fix installation of importlib.metadata (#13563)
https://github.com/python/cpython/commit/c3738cfe63b1f2c1dc4a28d0ff9adb4e9e3aae1f
Jason R. Coombs added the comment:
I started trying to replicate the failure. I got as far as this Dockerfile:
```
FROM fedora:rawhide
RUN yum install -y clang make git
RUN git clone https://github.com/python/cpython
WORKDIR cpython
RUN ./configure
RUN make
```
And then running `./python
Change by Jason R. Coombs :
--
pull_requests: +13124
___
Python tracker
<https://bugs.python.org/issue36832>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jason R. Coombs :
In working on some docs contributions, I've run into issues where docs builds
are failing in CI differently than they're failing locally.
Locally, running `make venv` from `Docs/` results in Sphinx 2, whereas on Azure
Pipelines, the docs are built
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +13070
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36832>
___
_
Change by Jason R. Coombs :
--
components: +Library (Lib)
type: -> enhancement
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issu
New submission from Jason R. Coombs :
The [zipp package](https://pypi.org/project/zipp) implements a
pathlib-compatable wrapper for zipfiles and is used by the importlib_metadata
project. The port of importlib_metadata to importlib.metadata (issue34632)
currently embeds that functionality
Change by Jason R. Coombs :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> zipimport needs to support namespace packages when no
'directory' entry exists
___
Python tracker
<https://
New submission from Jason R. Coombs :
As discovered in https://github.com/pypa/packaging-problems/issues/212, if a
PEP 420 namespace package is represented by an implicit directory (that is,
there's no explicit entry for the directory, only entries for the contents of
the directory
Jason R. Coombs added the comment:
Nice work. Thanks Raymond.
--
___
Python tracker
<https://bugs.python.org/issue36650>
___
___
Python-bugs-list mailin
Jason R. Coombs added the comment:
Hi Josh. Thanks for the tip on types.MethodType. I've updated the code to use
that and the behavior seems to be the same, MethodType does seem a more
appropriate way to create a bound method.
Regarding the referenced tickets, I suspect they're
Jason R. Coombs added the comment:
I've put together this full reproducer script:
```
import functools
def method_cache(method):
def wrapper(self, *args, **kwargs):
# it's the first call, replace the method with a cached, bound
method
bound_method
Change by Jason R. Coombs :
--
components: +Library (Lib)
type: -> behavior
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issu
New submission from Jason R. Coombs :
In [this ticket](https://github.com/jaraco/jaraco.functools/issues/12), I
learned that
[jaraco.functools.method_cache](https://github.com/jaraco/jaraco.functools/blob/6b32ee0dfd3e7c88f99e88cd87c35fa9b76f261f/jaraco/functools.py#L109-L180)
no longer works
Jason R. Coombs added the comment:
In PR 12824 (https://github.com/python/cpython/pull/12824), I've developed a
test that should assure the current output from uname().processor.
I've merged those changes with PR 12239, which if the tests pass, should
illustrate the values returned
Change by Jason R. Coombs :
--
pull_requests: +12749
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
> I don't quite follow: since you are the author of the tool, you can of
course have your uname.py import platform and then apply one of the
above tricks.
I thought I'd tried that, but failed
[ref](https://github.com/jaraco/cmdix/issues/1#issuecomm
Jason R. Coombs added the comment:
Confirmed the fix. Thank you very much!
--
___
Python tracker
<https://bugs.python.org/issue35512>
___
___
Python-bugs-list m
Change by Jason R. Coombs :
--
pull_requests: +12496
___
Python tracker
<https://bugs.python.org/issue34632>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jason R. Coombs :
--
pull_requests: +12227
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
> It's also easy to bypass that by simply seeding the global cache
> for uname(): _uname_cache.
> Or you could monkey-patch the platform module
> in your utility to work around the circular reference.
I don't think these options are possible in
Jason R. Coombs added the comment:
In [this
commit](https://github.com/jaraco/cpython/commit/acd024e2d4aa56f13d7bc165d10a35510e83a12b),
I demonstrate the alternative approach I was considering that avoids calling
"uname -p" until it's required, but otherwise retains compatibilit
Jason R. Coombs added the comment:
> Perhaps adding a more capable API to interface to /proc/cpuinfo
would be a good idea.
The core concern I want to address is that it's not possible to use any
function in the platform module without invoking "uname -p", and thus it's
Jason R. Coombs added the comment:
> the output of platform.uname() needs to stay compatible to what the function
> returned prior
Do we really wish to retain the output for this unreliable interface,
especially when it is not standardized and is returning improper infor
Jason R. Coombs added the comment:
Correction on last comment: s/Debian/Ubuntu/
--
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Python-bug
Jason R. Coombs added the comment:
[This answer](https://unix.stackexchange.com/a/307960/275034) is extremely
helpful. `uname -p` isn't available on Linux except Fedora and late versions of
Debian that apply the patch.
This lack of consistency means that `platform.uname().processor
Jason R. Coombs added the comment:
After fussing with sysctl for a while, I'm fairly confident that one can't use
sysctl on Linux reliably (https://stackoverflow.com/a/55066774/70170). I'll
keep digging to see if I can find another implementation of `uname` that's used
on Linux
Jason R. Coombs added the comment:
Hmm. But if I go to the Linux man page for uname
(https://linux.die.net/man/1/uname) and follow the links to the source code, I
end up at the same repository. So maybe the BSD man page is suitable for Linux.
I'll work from that assumption for now
Jason R. Coombs added the comment:
Reading further, the 'sysctl' call seems to only be for BSD
(https://www.freebsd.org/cgi/man.cgi?sysctl(3)). I could find the man page for
sysctl for BSD but not Linux. There is a _sysctl in Linux
(http://man7.org/linux/man-pages/man2/sysctl.2.html
Jason R. Coombs added the comment:
Best I can tell, neither sysinfo nor sysctl are exposed in any way to Python,
so it may not be possible to accurately load the processor information from
those system calls without writing a wrapper in C. What I might try is to
experiment with ctypes
Jason R. Coombs added the comment:
Aha! It seems the 'sysinfo' call is for Solaris:
https://docs.oracle.com/cd/E23823_01/html/816-5167/sysinfo-2.html
--
___
Python tracker
<https://bugs.python.org/issue35
Jason R. Coombs added the comment:
The first call I see in that routine is to "sysinfo", but the signature of that
function doesn't match what I find in the [man pages for that
function](http://man7.org/linux/man-pages/man2/sysinfo.2.html). So that
function must be coming from
Jason R. Coombs added the comment:
It won't be possible in general to emit what the function returned before, as
`uname` is a symbolic reference to an arbitrary executable, which can vary by
platform and release and local environment.
What I might be able to do is find the implementation
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +12217
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35967>
___
_
Change by Jason R. Coombs :
--
assignee: -> jaraco
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Python-bugs-list mai
Jason R. Coombs added the comment:
I agree that’s a good reproducer. Thanks for looking into this!
--
___
Python tracker
<https://bugs.python.org/issue35
Jason R. Coombs added the comment:
Nice insight Tim.
--
___
Python tracker
<https://bugs.python.org/issue35955>
___
___
Python-bugs-list mailing list
Unsub
Jason R. Coombs added the comment:
I don't think so, because the issue happens on a single line diff... although
it's plausible there's a common-mode fix.
--
___
Python tracker
<https://bugs.python.org/issue35
Jason R. Coombs added the comment:
I'm re-opening this issue as it does seem to apply stdlib (difflib.ndiff),
which is why I encountered it both in unittest and pytest. Thanks xtreak for
the distilled example.
--
resolution: third party ->
stage: resolved ->
status: closed -
New submission from Jason R. Coombs :
or: Unable to implement 'uname' on Python due to recursive call
or: platform.uname() should avoid calling `uname` in a subprocess
In [this issue](https://github.com/jaraco/cmdix/issues/1), I stumbled across a
strange and somewhat unintuitive behavior
Jason R. Coombs added the comment:
This issue now needs to consider that Mac OS X was renamed to macOS.
--
nosy: +jaraco
___
Python tracker
<https://bugs.python.org/issue7
Jason R. Coombs added the comment:
I was able to replicate the issue using pytest and not unittest, so I've
[reported the issue with that
project](https://github.com/pytest-dev/pytest/issues/4765).
--
___
Python tracker
<https://bugs.python.
Change by Jason R. Coombs :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
I should acknowledge that I'm using pytest here also... and pytest may be the
engine that's performing the reporting of the failed assertion.
In fact, switching to simple assertions, I see the same behavior, so I now
suspect the issue may lie with pytest
New submission from Jason R. Coombs :
In [this job](https://travis-ci.org/jaraco/cmdix/jobs/491246158), a project is
using assertEqual to compare two directory listings that don't match in the
group. But the hint markers pointing to the mismatch are pointing at positions
that match:
E
Jason R. Coombs added the comment:
In issue24209, I ended up settling on this implementation
(https://github.com/python/cpython/blob/f289084c83190cc72db4a70c58f007ec62e75247/Lib/http/server.py#L1227-L1234),
which seems to work well.
--
___
Python
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 f289084c83190cc72db4a70c58f007ec62e75247 by Jason R. Coombs in
branch 'master':
bpo-24209: In http.server script, rely on getaddrinfo to bind to preferred
address based on the bind parameter. (#11767)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
I also have a script that does something very similar
(https://github.com/jaraco/jaraco.develop/blob/master/jaraco/develop/macos-build-python.py),
invoked with `python -m jaraco.develop.macos-build-python` (or `pip-run -m
jaraco.develop -- -m
Change by Jason R. Coombs :
--
pull_requests: +11726, 11727, 11728
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Jason R. Coombs :
--
pull_requests: +11726
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue24209>
___
___
Python-
Change by Jason R. Coombs :
--
pull_requests: +11726, 11727
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue24209>
___
___
Py
Jason R. Coombs added the comment:
I don't believe the current patch as accepted has the right behaviors. First
off, the default behavior, which indicates "all interfaces" only binds to IPv4
interfaces. Additionally, "-b localhost" only binds to IPv4 localhost.
Idea
New submission from Jason R. Coombs :
In https://github.com/python/devguide/issues/453#issuecomment-460848565, I
understand that Ned wishes to update the macOS build docs prior to linking to
them from the dev guide.
--
assignee: docs@python
components: Documentation
messages: 334895
Jason R. Coombs added the comment:
Please refer to issue35891 for a description of an important use-case broken by
the planned removal of splituser.
--
nosy: +jason.coombs
___
Python tracker
<https://bugs.python.org/issue27
New submission from Jason R. Coombs :
The removal of splituser (issue27485) has the undesirable effect of leaving the
programmer without a suitable alternative. The deprecation warning states to
use `urlparse` instead, but `urlparse` doesn't provide the access to the
`credential` or `address
Change by Jason R. Coombs :
--
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue35891>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
> `site.addsitedir` is called for every site-packages directory (whether
> global, within a venv, or at the user level), so my proposal above covers
> appending multiple segments.
Good point. I think you're assuming that only site dirs are ap
Jason R. Coombs added the comment:
I like Nick's proposal. It has I believe the features that satisfy the
use-cases of which I'm currently aware... with one edge case you may not have
considered - support for multiple `__sitecustomize__` locations.
Consider, for example, the case where
Jason R. Coombs added the comment:
I do believe this issue is still important and relevant. See issue25667 for a
duplicate ticket (and references to implementations) and issue24209 for another
issue where this could have been applied.
--
nosy: +jason.coombs
versions: +Python 3.8
Jason R. Coombs added the comment:
I believe this issue is a duplicate of 17561, which I stumbled onto today.
--
resolution: -> duplicate
superseder: -> Add socket.create_server_sock() convenience function
___
Python tracker
New submission from Jason R. Coombs :
Originally [reported in
testing-cabal/mock#405](https://github.com/testing-cabal/mock/issues/405), I
believe I've discovered an inconsistency that manifests as a flaw:
`patch` and `patch.object` allow the target to be specified as string referring
Jason R. Coombs added the comment:
I don't think this ticket should be implemented as described.
Consider the use-case in importlib_metadata, which loads metadata from a
package, metadata known to be of a specified encoding. It already knows the
encoding and has decoded the full message
Jason R. Coombs added the comment:
Regarding other uses of .pth files, the project
[future-fstrings](https://github.com/asottile/future-fstrings) relies on .pth
files to enable its at-startup behavior.
I'm also +1 to remove .pth files, but I also believe it's not viable today due
701 - 800 of 1492 matches
Mail list logo
