Nick Coghlan 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 while I d
New submission from Nick Coghlan :
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 through to
type.__new__.
Now
Nick Coghlan 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 tracker
<https://bugs.python.org/is
Nick Coghlan 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_class__ needs a way to
Nick Coghlan 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 certainly the intenti
Nick Coghlan 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 tracker
<https://bugs.python.
Nick Coghlan 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
<https://bugs.python.org/issu
Change by Nick Coghlan :
--
pull_requests: +6028
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33182>
___
___
Python-bugs-list mai
Nick Coghlan 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.
Ned: the ch
Nick Coghlan 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/69f5c73311a61b05485b19626935bf
Nick Coghlan 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/commit/2961717986201d639b60de51e5f2e9
Nick Coghlan 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: patch review -> resolved
status
Nick Coghlan 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 cleaning up improperly
decoded d
Nick Coghlan 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
versions: +P
Nick Coghlan 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 checkout without a virtual e
Nick Coghlan 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 removing "
Nick Coghlan 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. (Note that only some APIs could be
Nick Coghlan 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 reported: in order fo
Nick Coghlan 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
"prefix" option (
Nick Coghlan 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 case?:
AttributeError: p
Nick Coghlan 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
Nick Coghlan 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 current working directory
Change by Nick Coghlan :
--
nosy: +encukou, ncoghlan
___
Python tracker
<https://bugs.python.org/issue15727>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +6122
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Nick Coghlan :
--
stage: patch review -> commit review
___
Python tracker
<https://bugs.python.org/issue33185>
___
___
Python-bugs-list mai
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue1230540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue26979>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan 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 separate performance issue
Nick Coghlan 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
prerequisite for being able to convey
Nick Coghlan 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 :)
--
nosy: +yseli
Nick Coghlan 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/cpyt
Nick Coghlan 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 -> closed
type: -> performance
versi
Nick Coghlan 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 actually a bug: the problem is
Nick Coghlan 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 same
way `inspect.signature`
Nick Coghlan 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 will
automatically merge i
Change by Nick Coghlan :
--
pull_requests: +6177
___
Python tracker
<https://bugs.python.org/issue33185>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan 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/1a5c4bdb6ecc6a8b19ff33bde323ab
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan 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 clear
Nick Coghlan 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 tracker
<https://bugs.py
Nick Coghlan 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 C API, not as a core-only int
Nick Coghlan 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/cpyt
Nick Coghlan 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 think
that would make more
Nick Coghlan 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/importlib.html also doesn&
Change by Nick Coghlan :
--
assignee: -> paul.moore
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Nick Coghlan 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->AST step ex
Nick Coghlan 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:
return module.__file__
Nick Coghlan 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/cpyt
Nick Coghlan 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
___
Python tracker
<https://bug
Nick Coghlan 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 match a
fully unrolled loop
New submission from Nick Coghlan :
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 modules like GNU readline),
the interacti
Nick Coghlan 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.org/specifications/entry-poin
Nick Coghlan 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 thought.
That said, as long
New submission from Nick Coghlan :
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
worthwhile deferri
Nick Coghlan 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/cpyt
Nick Coghlan 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: patch review -> resol
New submission from Nick Coghlan :
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/finally down in the con
Nick Coghlan added the comment:
Aye, it is - while there's no venv integration in 2.7 (since there's no venv
module), ensurepip itself is essentially identical across the two version, so
2.7 will suffer from the same problem.
--
stage: patch review -> backport ne
Nick Coghlan added the comment:
New changeset cf7197ae43767c4346864e5b41246f628edd9b51 by Nick Coghlan (Igor
Filatov) in branch '2.7':
[2.7] bpo-31351: Set return code in ensurepip when pip fails (GH-3734)
https://github.com/python/cpython/commit/cf7197ae43767c4346864e5b41246f
Nick Coghlan added the comment:
And done - thanks for the report and PRs, Igor!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
The main downside I see to that approach is that it would still require quite a
few client code changes to restore compatibility for folks upgrading from 2.7,
and even though six could add a "six.Prioritize" backport, it would still be
difficult for
Nick Coghlan added the comment:
My rationale for asking "What if we just changed heapq back to working closer
to the way it used to work?" is that it's a case where arbitrarily ordering
unorderable tuples made sense, and reverting it to the old behaviour is
reasonably safe:
-
Nick Coghlan added the comment:
Let's call it done with the current sys.getrecursionlimit() behaviour, and if
that turns out to be problematic in practice, someone will hopefully file a new
issue about it.
--
resolution: -> fixed
stage: patch review -> resolved
s
Nick Coghlan added the comment:
There's no __prepare__ method in 2.7, so that version can't be affected by this.
For 3.6 and 3.7, I can't reproduce the reported SystemError. Instead, I get:
```
>>> class BadMetaclass(type):
... def __prepare__(*args):
...
Nick Coghlan added the comment:
Aye, that's exactly what I did.
--
___
Python tracker
<https://bugs.python.org/issue31588>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
New changeset 5837d0418f47933b2e3c139bdee8a79c248a943c by Nick Coghlan (Oren
Milman) in branch 'master':
bpo-31588: Validate return value of __prepare__() methods (GH-3764)
https://github.com/python/cpython/commit/5837d0418f47933b2e3c139bdee8a7
Nick Coghlan added the comment:
CI is still running for the backport, so I'll merge that tomorrow.
Thanks for the patch!
--
resolution: -> fixed
stage: patch review -> backport needed
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
New changeset 084f80b82c564c8a3cef26fc6e56da188a379be2 by Nick Coghlan (Miss
Islington (bot)) in branch '3.6':
[3.6] bpo-31588: Validate return value of __prepare__() methods (GH-3790)
https://github.com/python/cpyt
Change by Nick Coghlan :
--
stage: backport needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue31588>
___
___
Pyth
Nick Coghlan added the comment:
Note that it would be entirely possible to leave the Python level thread IDs
alone, but change the way they were used internally to keep the thread ID
distinct from the operating system level thread handle.
That would limit the adjustment to
Nick Coghlan added the comment:
No, I'm not currently working on this (to be completely honest, I entirely
forgot we hadn't backported the What's New updates to the various branches).
They'll need to be independent updates, since they affect a different file for
each re
Nick Coghlan added the comment:
Of the listed benefits, I think the most interesting one is the fact it would
enable pip's wheel cache by default for all installations, rather than relying
on projects publishing pre-built wheel files to PyPI.
However, actually doing this would run count
Nick Coghlan added the comment:
As a shorter version of the above:
* the current install time bundling of setuptools in `ensurepip` is likely to
be replaced by `pip` dynamically installing both `setuptools` & `wheel` when
asked to build from a source archive when no other build system
Nick Coghlan added the comment:
I'm unlikely to ever get to this (especially as 3.5 is now in security-fix only
mode), so closing it again.
--
nosy: +freakboy, freakboy3742
resolution: -> fixed
stage: needs patch -> resolved
status: ope
Nick Coghlan added the comment:
This has been merged now:
https://github.com/python/cpython/commit/731e18901484c75b60167a06a0ba0719a6d4827d
Thank you for the PEP & implementation! :)
--
resolution: -> fixed
stage: patch review -> resolved
status: open
Nick Coghlan added the comment:
Oops, we/I missed the window for also getting the deprecation removed from
3.5.x (as that branch is now in security-fix only mode).
Marking as resolved for 3.6 accordingly.
--
resolution: -> fixed
stage: backport needed -> resolved
status
New submission from Nick Coghlan :
Chatting to Donald Stufft and Amber Brown about the way we currently handle
provisional APIs, I think they have a legitimate concern that we may not be
gathering adequately informed consent from users when they depend on APIs that
we've reserved the rig
Nick Coghlan added the comment:
Another advantage of this approach: anyone running their tests in a "no
warnings allowed" configuration would get a hard failure when dependencies on a
provisional API were unexpectedly introduced (e.g. when updating a third party
library), r
Nick Coghlan added the comment:
This is also fairly similar to Rust's approach of using feature flags to
explicitly opt-in to unstable features: https://doc.rust-lang.org/unstable-book/
--
___
Python tracker
<https://bugs.python.org/is
Nick Coghlan added the comment:
Larry, your personal insult is entirely unwelcome, unnecessary, and
unappreciated, especially as it's wrong regarding the Python 2/3 compatibility
concerns.
While getfullargspec() is indeed new in Python 3.x, it's also deliberately
designed as
Nick Coghlan added the comment:
Note: the minor incompatibility that required getfullargspec() to be a separate
API in the first place is the fact that it returns a 7 element named tuple
instead of a 4 element one.
This means that hybrid 2/3 code needs to consistently use name based item
Nick Coghlan added the comment:
I think if someone is going to be put off by a FutureWarning, then that
indicates they're not yet familiar with just what the provisional API status
means, and those are exactly the folks we *want* to scare away from provisional
APIs (or features in
Nick Coghlan added the comment:
Deprecation warnings were different: we turned those off by default because
currently working applications could start emitting console warnings simply
because an end user ran them on a newer version of Python.
With future warnings, we're instead tryi
Nick Coghlan added the comment:
A note regarding *only* using the warnings module to turn things off:
The problem I have with that is that the UX is relatively clumsy, and hence
runs into the concern Guido mentions above: "having this warning pop up every
time you import a provisional m
Nick Coghlan added the comment:
The deprecation warnings weren't turned off due to Python developers running
things in virtual environments - they were turned off due to Linux distros
upgrading their system Python runtimes, and Linux ISVs getting an influx of new
bug reports from their
Nick Coghlan added the comment:
I've been thinking further about the write-through proxy idea, and I think I've
come up with a design for one that shouldn't be too hard to implement, while
also avoiding all of the problems that we want to avoid.
The core of the idea is that
Nick Coghlan added the comment:
Nathaniel raised a valid concern about the draft PEP over in
https://bugs.python.org/issue30744#msg302475, so I've been considering whether
or not it would be possible to make the write-through proxy idea work without
introducing other problems.
I th
Nick Coghlan added the comment:
This still seems like a reasonable enhancement, but would presumably need
updates to apply against the 3.7 development branch.
--
versions: +Python 3.7 -Python 3.3
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
A note regarding applicability if we did make a change to our approach:
* asyncio & pathlib are already non-provisional, so wouldn't be affected.
* typing is still provisional, but introducing a new FutureWarning after two
releases without one
Nick Coghlan added the comment:
This discussion should probably be submitted as a new RFE (requesting "text" as
a more obvious and beginner friendly alias for universal_newlines), but I'll
also add a note regarding precedent for a simple binary/text toggle: the mode
se
Nick Coghlan added the comment:
As far as docs phrasing goes, it probably makes sense to frame it as "text"
being the preferred argument name in 3.7+, with "universal_newlines" retained
indefinitely as a compatibility preserving alias. After all, if that wasn't our
Nick Coghlan added the comment:
Thinking about the interaction between this idea and
https://bugs.python.org/issue30744 made me realise that there's a subtlety here
that would probably need to be spelled out more clearly in the docs for
__closure__ than it is for __code__: any changes
Nick Coghlan added the comment:
If a proposed standard library API is sufficiently stable that the folks
proposing it are reluctant to emit a runtime warning about any remaining
stability risks, then I think it's reasonable to expect them to propose it as
non-provisional and accep
Nick Coghlan added the comment:
Increasing the number of stat calls required for a successful import is a good
reason to close the submitted PR, but I'm not sure it's a good reason to close
the *issue*, as there may be other ways to solve it that don't result in an
extra stat
Nick Coghlan added the comment:
Aye, what's in PEP 558 is the least invasive implementation change I've been
able to come up that fixes the reported bug, but Nathaniel's right that it
would break debuggers (and probably some other things) as currently written.
So the above de
Nick Coghlan added the comment:
Keep in mind that I'm not proposing that we retroactively change our approach
to managing any currently provisional APIs that were proposed and implemented
under the current version of PEP 411.
Instead I'm merely suggesting that the policy for a
Nick Coghlan added the comment:
The problem with changing the bytecode format is that code other than the
import machinery reads the bytecode headers, so when we change the format, we
need to consider the impact on that code. (Even my multiplication proposal
above suffers from that problem
Nick Coghlan added the comment:
If there's no hot reloader forcing a reimport for every saved edit, it's
sufficiently unlikely to encounter this problem in the first place that I'm not
worried about that scenario. (The time required for a human to context switch
from code
Nick Coghlan added the comment:
I wasn't clear on what you meant by "potentially in the future".
Now that I realise you meant "Defer refreshing the bytecode cache to the next
import attempt if `int(source_mtime) == int(time.time())`, but still bypass it
for the current
Nick Coghlan added the comment:
We're OK with the idea that installing a trace function might automatically
turn off various compiler and interpreter managed optimisations (it's similar
to how requesting or implying reliance on full frame support in other
implementations can disab
2401 - 2500 of 6301 matches
Mail list logo
