Nick Coghlan <ncogh...@gmail.com> added the comment:
Yes, while weird, that's expected behaviour.
Rather than being due to absolute vs relative imports, the difference arises
from the fact that in "import pkg.module", the request is explicitly for a
submodule, so the submodu
Nick Coghlan <ncogh...@gmail.com> added the comment:
Adding a low level callback based mechanism to ask another interpreter to do
work seems like a good way to go to me.
As an example of why that might be needed, consider the case of sharing a
buffer exporting object with a
Nick Coghlan <ncogh...@gmail.com> added the comment:
Rather than tracking this per object, you could potentially track it per arena
at the memory allocator level instead. Then if you really need the info (e.g.
when running the debug allocator), you can check it in a reliab
Nick Coghlan <ncogh...@gmail.com> added the comment:
Also see
https://github.com/python/cpython/blob/55edd0c185ad2d895b5d73e47d67049bc156b654/Objects/exceptions.c#L2713
for the version we use in a few places to implicitly update the exception
message, while keeping the exceptio
Nick McElwaine <nmcelwa...@gmail.com> added the comment:
Thankyou for clearing that up!
On 18 May 2018 at 13:05, Berker Peksag <rep...@bugs.python.org> wrote:
>
> Berker Peksag <berker.pek...@gmail.com> added the comment:
>
> Thanks for the report. I agree w
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think the reference to RuntimeWarning in the docs is a typo (if it was only
going to be a warning, it could have been that from the start), and that
reference to RuntimeError in the code comment is correct.
So there's also a do
Nick Coghlan <ncogh...@gmail.com> added the comment:
Yeah, the "transparent exception chaining" code falls into the category of code
that I'm both proud of (since it works really well in typical cases [1]) and
somewhat horrified by (since the *way* it works tramples over sev
Nick Coghlan <ncogh...@gmail.com> added the comment:
While it does match Christian's original suggestion, I'm not taking the "bytes"
in the issue title as literally requiring that the feature be implemented as
operator support on the bytes type (implementing it on memoryvi
Nick Coghlan <ncogh...@gmail.com> added the comment:
Hmm, I wonder if the UX problem with the current chaining might be solved in a
different way, by doing something similar to what we did for codec exceptions
(where we want to try to mention the codec name, but also don't want to
Nick Coghlan <ncogh...@gmail.com> added the comment:
I filed https://bugs.python.org/issue33576 to cover removing the exception
wrapping from __set_name__ errors.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Nick Coghlan <ncogh...@gmail.com>:
Type creation currently wraps all exceptions raised by __set_name__ calls with
a generic RuntimeError:
https://github.com/python/cpython/blob/master/Objects/typeobject.c#L7263
Unfortunately, this makes it difficult to use __set_
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think it would make sense to remove the exception wrapping from the
__set_name__ calls - I don't think we're improving the ease of understanding
the tracebacks by converting everything to a generic RuntimeError, and we're
hurting
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think Antoine's right that another venue (such as python-ideas) might be a
better venue for this discussion, but I'll still try to explain the potential
analogy I see to bytes.upper()/.lower()/etc: those operations let you treat
Nick Coghlan <ncogh...@gmail.com> added the comment:
I believe the main argument for -X options is the fact that cmd on Windows
doesn't offer a nice way of setting environment variables as part of the
command invocation (hence "-X utf8", for example).
As far as setting valu
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thanks for the link Serhiy (I'd forgotten about the struct changes proposed in
PEP 3118), but the existing struct formatting codes are fine for my purposes.
The question is whether we might be able to avoid some
bytes->Python-objec
Nick Coghlan <ncogh...@gmail.com> added the comment:
This issue isn't at the stage where a PR would help - the core question is
still "Should we add better native support for multi-byte bitwise operations?",
not the specifics of what they API might look like or how we
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'm back in the embedded software world now, and hence working with the
combination of:
- low level serial formats (including fixed length CAN packets)
- C firmware developers that are quite capable of writing supporting
C-in-Pytho
Nick Coghlan <ncogh...@gmail.com> added the comment:
Issue 19251 is still under consideration, so marking this as a duplicate,
rather than as rejected.
--
nosy: +ncoghlan
resolution: rejected -> duplicate
superseder: -> bitwise ops for bytes of
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ah, sorry, I misinterpreted Petr's comment, and then didn't look at the details
of your PR before commenting.
Having fixed that mistake, I agree that making the naive approach "just work"
Nick Coghlan <ncogh...@gmail.com> added the comment:
Regarding environment variables, note that they get used in two *very*
different ways:
1. The "persistent shell setting" case that Raymond describes. While setting
PYTHONBYTECODEPATH to always point to a RAM disk could
Nick Coghlan <ncogh...@gmail.com> added the comment:
As David notes, the issue in the example is the fact that you're setting
"__main__.a", so "a.py" never gets imported as a module - it gets a hit on the
parent module attribute, and hence stops there.
--
Nick Coghlan <ncogh...@gmail.com> added the comment:
The behaviour I'd expect to see:
"module:qual.name" -> "imports module, accesses module.qual.name"
"module.qual.name" -> "no implicit import, accesses module.qual.name"
"package.sub
Nick Coghlan <ncogh...@gmail.com> added the comment:
I've assigned the PR and issue to myself, as the proposed addition in the PR
isn't quite right, but it isn't immediately obvious why not.
The gist of the problem is that the current docs are actually correct and
complete: m
Nick Coghlan <ncogh...@gmail.com> added the comment:
If these warnings are being emitted when using setuptools, that's a bug in
setuptools (as it should be ensuring these are handled without warnings), and
can be reported over on https://github.com/pypa/setuptools/
If these warnings are
Nick Coghlan <ncogh...@gmail.com> added the comment:
PSF link for Diana Clark's thread on python-ideas about this:
https://mail.python.org/pipermail/python-ideas/2017-September/047224.html (this
is the same thread Brett linked, just to the PSF archives rather than Google
New submission from Nick Coghlan <ncogh...@gmail.com>:
The current example for contextlib.contextmanager doesn't use try/finally,
which sets folks up for writing resource management context managers that don't
clean up after exceptions properly.
There's an example with try/finall
Nick Coghlan <ncogh...@gmail.com> added the comment:
Marking as closed/later to indicate that we're not going to pursue this in the
near term, but it's not out of the question that we might accept a future
proposal along these lines.
--
resolution: -> later
stage: pat
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset df00f048250b9a07195b0e3b1c5c0161fdcc9db8 by Nick Coghlan (Serhiy
Storchaka) in branch 'master':
bpo-26701: Tweak the documentation for special methods in int(). (GH-6741)
https://github.com/python/cpython/
New submission from Nick Coghlan <ncogh...@gmail.com>:
Due to a python-ideas discussion about reducing boilerplate for
__file__-relative path calculations, I was running "./python -X importtime -S
-c 'import pathlib'" and noticed three potential candidates where it may be
wort
Nick Coghlan <ncogh...@gmail.com> added the comment:
Note that Neil did start with a python-ideas discussion, and was directed over
here, since the idea seemed simple enough, and worth pursuing.
As Serhiy notes though, there are many more subtleties to be addressed here
than I first t
Nick Coghlan <ncogh...@gmail.com> added the comment:
"package.module:attribute" is also the syntax used in packaging tools to
unambiguously separate the name of the module to be imported from the attribute
chain to be looked up within that module:
https://packaging.python.or
Nick Timkovich <prometheus...@gmail.com> added the comment:
Was this patch mostly ready to go? The additional SHA512 variants are appealing
because they run ~40% faster than SHA256 on 64-bit hardware for longer messages.
--
nosy: +nic
New submission from Nick Coghlan <ncogh...@gmail.com>:
While Victor and I reconciled the respective designs & implementations of PEP
538/540 (with 538 relying on 540 to handle the "No suitable target locale"
case, and 540 relying on 538 to handle extension modul
Nick Coghlan <ncogh...@gmail.com> added the comment:
The current discrepancy is odd when you compare it to the equivalent generator
expression:
{k:v for k, v in iterable}
dict(((k, v) for k, v in iterable))
It would never have occurred to me to expect the evaluation order to
Nick Coghlan <ncogh...@gmail.com> added the comment:
Hartmut, thanks for the issue report, and Pablo, thanks for the PR to resolve
it!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pyth
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 0977091dca59709864b14cfc129388f1f0de7bf7 by Nick Coghlan (Pablo
Galindo) in branch 'master':
bpo-33128 Fix duplicated call to importlib._install_external_importers
(GH-6273)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
As a concrete proposal for 3.8, how about:
1. Add the following utility functions to importlib.util (names adjusted to
match PEP 451 rather than my initial suggestions above):
def get_location(module):
try:
Nick Coghlan <ncogh...@gmail.com> added the comment:
If I recall Eugene Toder's previous AST-level compilation patches correctly,
they handle this problem by putting the AST optimisation step *after* the
output of the Py_CF_ONLY_AST step.
This meant that if you're running the source->
Change by Nick Coghlan <ncogh...@gmail.com>:
--
assignee: -> paul.moore
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https:/
Nick Coghlan <ncogh...@gmail.com> added the comment:
-1 from me for __package__, as setting that's the preferred way for directly
executed scripts to fix their explicit relative imports (rather than trying to
retroactively fix their spec).
(https://docs.python.org/3/library/importli
Nick Coghlan <ncogh...@gmail.com> added the comment:
Xavier's changes should fix the reported compile error, while keeping the
increased isolation of the interpreter core from the optional extension modules.
If the latter change causes a detectable performance regression, then I
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 063db62aab4041ac47798e7e48b27b2f2bef21c5 by Nick Coghlan
(xdegaye) in branch 'master':
bpo-32232: by default, Setup modules are no longer built with -DPy_BUILD_CORE
(GH-6489)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
I also resolved my own puzzlement from the PR comments regarding why
_weakrefs.c was fine with being built as a regular extension module: it's
because the C level access API for __weakrefs__ is published through the
regular
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ah, oops - I commented before fully catching up on everything else, and now I
see that Xavier already made exactly that point just above.
I'll go review the PR now :)
--
___
Python tracke
Nick Coghlan <ncogh...@gmail.com> added the comment:
Even when statically linked, extension modules should *NOT* be getting built
with `-DPy_BUILD_CORE`. That preprocessor definition is for CPython core core
only, and we moved the headers to help make that 100% crystal
Change by Nick Coghlan <ncogh...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 1a5c4bdb6ecc6a8b19ff33bde323ab188ed60977 by Nick Coghlan in
branch 'master':
bpo-33185: Improve wording and markup (GH-6477)
https://github.com/python/cpython/commit/1a5c4bdb6ecc6a8b19ff33bde323ab188e
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +6177
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33185>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
Merge to master and set the "needs backport to 3.7" label for the initial PR -
the backport bot will then take care of creating the 3.7 PR. For the backport,
all you then need to do is leave an Approve review, and the bot wil
Nick Coghlan <ncogh...@gmail.com> added the comment:
Terry, if you'd like to continue that discussion, please open a new enhancement
request for 3.8+ against the inspect module asking for the affected
introspection functions to recursively search for relevant attributes, the sam
Nick Coghlan <ncogh...@gmail.com> added the comment:
The inspect functions throwing an exception when handed a method wrapping a
non-function callable instead of returning False is a definite bug.
The behaviour of MethodType when handed a non-function callable is cryptic, but
not ac
Nick Coghlan <ncogh...@gmail.com> added the comment:
Classifying this as a minor performance enhancement, since methods are much
simpler objects than full Python level closures.
Thanks!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 23ab5ee667a9b29014f6f7f01797c611f63ff743 by Nick Coghlan
(jdemeyer) in branch 'master':
bpo-33265: use an actual method instead of a method-like function in ExitStack
(GH-6456)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
Yury, could you double check the async exit stack change in the PR? I think
it's fine since the bound method just passes back the underlying coroutine and
the tests all still pass, but a second opinion would be good :)
-
Nick Coghlan <ncogh...@gmail.com> added the comment:
+1 from me for further ResourceWarning docs improvements - my focus when
working on PEP 565 was the actual change in how DeprecationWarning was being
handled, and the other warnings doc improvements were just a necessary
prereq
Nick Coghlan <ncogh...@gmail.com> added the comment:
The main idea that comes to mind is to cache a reference to
`_frozen_importlib._module_locks` in the interpreter state, and do a key lookup
in there (since any in-progress import should have a lock allocated to it).
That would be a se
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26979>
___
__
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue1230540>
___
_
Change by Nick Coghlan <ncogh...@gmail.com>:
--
stage: patch review -> commit review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nick Coghlan <ncogh...@gmail.com>:
--
keywords: +patch
pull_requests: +6122
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +encukou, ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue15727>
___
Nick Coghlan <ncogh...@gmail.com> added the comment:
Some notes from my investigation of bpo-33185 that seem more appropriate here,
rather than on that issue:
* several of the developer-centric utilities in the standard library have a
shared need to be friendly to imports from the c
Nick Coghlan <ncogh...@gmail.com> added the comment:
Oops, just realised my suggested text had an extraneous double quote in it due
to a copy-and-paste error. Fixed version:
AttributeError: partially initialized module 'spam' has no attribute 'ham'
(most likely due to a circular
Nick Coghlan <ncogh...@gmail.com> added the comment:
While I like the idea of this change, the "partially initialized" addition is
fairly subtle, and relatively easy to miss.
Perhaps append "(most likely due to a circular import)" to the partially
initialized
Nick Coghlan <ncogh...@gmail.com> added the comment:
https://bugs.python.org/issue29258 is an existing issue for the PEP 420
limitation (it also notes why fixing that implicitly is a potential problem)
I've retitled this issue to be specifically about the misleading docs for the
&
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think this is actually two distinct problems, one documentation one (which
should be addressed in the online docs for all currently maintained versions),
and one actual functional issue.
The documentation issue is the one you've re
Nick Coghlan <ncogh...@gmail.com> added the comment:
+1 for switching over to `iterable` in the reduce docstring.
As a possible enhancement for 3.8+ only, it would be reasonable to start
converting functools over to Argument Clinic in order to improve the
introspection support.
Nick Coghlan <ncogh...@gmail.com> added the comment:
It turns out pydoc's CLI is looking specifically for '' in sys.path, but *not*
looking for "os.getcwd()".
The resulting sys.path manipulation then goes completely wrong for "python -m
pydoc", since it ends up
Nick Coghlan <ncogh...@gmail.com> added the comment:
I guess this confirms our suspicion from issue 33053 that making "-m" no longer
track the current working directory had the potential to pose some non-trivial
compatibility risks :(
I can reproduce the issue in a 3.7
Nick Coghlan <ncogh...@gmail.com> added the comment:
Tidying up old git branches, and I noticed this was still open even though
Larry had long ago merged the PR.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versio
Nick Coghlan <ncogh...@gmail.com> added the comment:
With PEPs 538 and 540 implemented for 3.7, my thinking on this has evolved a
bit.
A recent discussion on python-ideas [1] also introduced me to the third party
library, "ftfy", which offers a wide range of tools for cleani
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thanks for the bug report - the 3.7 branch should be buildable again now.
My assumption would be that Travis are still running clang 5, since 6 was only
released very recently.
--
resolution: -> fixed
stage: pat
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 2961717986201d639b60de51e5f2e9aa2573856c by Nick Coghlan (Miss
Islington (bot)) in branch '3.7':
bpo-33182: Fix pointer types in _testembed (GH-6310) (GH-6311)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 69f5c73311a61b05485b19626935bf240ad31c5b by Nick Coghlan in
branch 'master':
bpo-33182: Fix pointer types in _testembed (GH-6310)
https://github.com/python/cpython/commit/69f5c73311a61b05485b19626935bf240a
Nick Coghlan <ncogh...@gmail.com> added the comment:
I agree that we can't change 3.6 at this late stage, but the change is
borderline enough on the "new feature"/"bug fix" scale that I think it's worth
asking Ned if he's comfortable with us changing it for 3.7.0b4.
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +6028
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Nick Coghlan <ncogh...@gmail.com> added the comment:
Huh, I thought we had a clang builder in the pre-merge CI. Is that running an
older version of clang, perhaps?
--
assignee: -> ncoghlan
___
Python tracker <rep...@bugs.python
Nick Coghlan <ncogh...@gmail.com> added the comment:
Also mentioning
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.set_executable,
since it came up on the pickle-protocol-version-5 thread.
--
___
Python tracke
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'm not sure what the right solution is at the design level, but I did recently
run into a quirk related to this in the embedding tests: on \*nix systems,
PySys_SetProgramName affects sys.executable, while Windows ignores it.
But cer
Nick Coghlan <ncogh...@gmail.com> added the comment:
Note that this isn't about the __class__ reference itself - that would still be
a closure cell.
This issue is about the fact that since Python 3.6, type.__new__ has handled
calling __set_name__ on all the descriptors, so __build_c
Nick Coghlan <ncogh...@gmail.com> added the comment:
The locale module has its own extra layer of oddities that I don't personally
understand - #29571 and #20087 are another couple of issues along those lines.
--
___
Python tracke
New submission from Nick Coghlan <ncogh...@gmail.com>:
As noted in
https://docs.python.org/3/reference/datamodel.html?#creating-the-class-object,
implementing PEP 487 required the introduction of __classcell__ as a way for
__build_class__ to pass the zero-arg super() cell object t
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ned, I'd forgotten about the part of this issue which amounts to "Check for
'POSIX' as a locale coercion trigger in addition to 'C', as not every platform
aliases the former to the latter the way glibc does".
So whi
Nick Coghlan <ncogh...@gmail.com> added the comment:
Added Łukasz to the nosy list, as I'd like his +1 before accepting this change
(I do still think it's a good idea, for the same reasons we added
partialmethod).
--
nosy: +lukasz.langa, nc
Nick Coghlan <ncogh...@gmail.com> added the comment:
It's a useful data point for folks trying to diagnose post-maintenance-update
failures when we upgrade pip on their behalf, rather than them explicitly doing
it themselves.
--
___
Python t
Nick Coghlan <ncogh...@gmail.com> added the comment:
Calling initexternalimports InitalizeMainInterpreter and from new_interpreter
is right, since we only want these importers on the metapath after we know
sys.path has been configured appropriately.
It's the call from InitializeCore
Nick Coghlan <ncogh...@gmail.com> added the comment:
Given that issue 32002 and issue 30672 track the known challenges in testing
the expected locale coercion behaviour reliably, I'm going to go ahead and
close this overall implementation issue (the feature is there, and works in a
way
New submission from Nick Coghlan <ncogh...@gmail.com>:
warnings.warn() offers a stacklevel parameter to make it easier to write helper
functions that generate warnings - by passing "stacklevel=2", you can ensure
the warning is attributed to the caller of the helper funct
Nick Coghlan <ncogh...@gmail.com> added the comment:
I wouldn't expand the scope of contextlib.suppress, since it has a pretty clear
purpose: pretend the exception never happened. (This was even clearer with the
original "ignored" name, before I was talked into changing it to
Nick Coghlan <ncogh...@gmail.com> added the comment:
Just noting that while I've closed this issue as fixed, I think we still have
quite a bit of work to do to get our handling of these pre-init config settings
to a place we're genuinely happy with (or as happy as backwards compati
Change by Nick Coghlan <ncogh...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Nick Coghlan <ncogh...@gmail.com> added the comment:
Harmut, thanks for the status update!
Victor, the problem is that both sys.warnoptions and sys._xoptions get read by
Py_Initialize(), so setting them afterwards is essentially pointless - while
you do still change the contents of t
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset ee3784594b33c72c3fdca6a71892d22f14045ab6 by Nick Coghlan in
branch '3.7':
bpo-33053: -m now adds *starting* directory to sys.path (GH-6231) (#6236)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset d5d9e02dd3c6df06a8dd9ce75ee9b52976420a8b by Nick Coghlan in
branch 'master':
bpo-33053: -m now adds *starting* directory to sys.path (GH-6231)
https://github.com/python/cpython/commit/d5d9e02dd3c6df06a8dd9ce75ee9b52976
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset bc77eff8b96be4f035e665ab35c1d06e22f46491 by Nick Coghlan in
branch 'master':
bpo-33042: Fix pre-initialization sys module configuration (GH-6157)
https://github.com/python/cpython/commit/bc77eff8b96be4f035e665ab35c1d06e22
Nick Coghlan <ncogh...@gmail.com> added the comment:
Marking as fixed, since this is now the version likely to go out in 3.7.0b3 -
if we find further problems with it (beyond the potential enhancement discussed
above to make local directory usage opt-in), then those can go in a new
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset a9e5d0e9ef27b14e34631d415e727a07d0f63bef by Nick Coghlan in
branch 'master':
bpo-33053: Remove test_cmd_line_script debugging print (GH-6237)
https://github.com/python/cpython/commit/a9e5d0e9ef27b14e34631d415e727a07d0
Nick Coghlan <ncogh...@gmail.com> added the comment:
3.7 CI finished before I logged off for the night, so this is good to go for
3.7.0b3 now :)
--
priority: release blocker -> normal
___
Python tracker <rep...@bugs.python
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +5974
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33053>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
Initial fix has been merged to master, CI runs pending for the backport to 3.7
and a follow-up master branch PR to remove a debugging print I noticed when
resolving a test_import conflict in the backport.
I won't get to merging those
601 - 700 of 8215 matches
Mail list logo
