New submission from Nick Coghlan <ncogh...@gmail.com>:
This is a potential follow-up to issue 31898, whereby the recommended packages
list could be taken into account as part of CPython's own testing regime. The
gist of the idea would be to:
1. Update the recommended-packages list to no
Change by Nick Coghlan <ncogh...@gmail.com>:
--
stage: -> needs patch
type: -> enhancement
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
New submission from Nick Coghlan <ncogh...@gmail.com>:
As per the python-ideas thread starting at
https://mail.python.org/pipermail/python-ideas/2017-October/047508.html, this
is proposal to add a `pip -r` compatible `recommended-packages.txt` file to the
`venv` documentation that summ
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thinking back to my signal processing days, I have to agree that our weightings
(filter definitions) were usually separate from our data (live signals).
Similarly, systems engineering trade studies all maintained feature weights
sepa
Nick Coghlan <ncogh...@gmail.com> added the comment:
A recent numpy threaded import bug report that appears in 3.6.1 but is absent
in 3.6.3: https://github.com/numpy/numpy/issues/9931
So that's additional evidence that this really was a pre-existing race
condition that the new
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thanks for the patch!
--
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 031c4bfadb69feeda82ce886d6b0cadc638d2e1e by Nick Coghlan (Erik
Bray) in branch 'master':
bpo-31877: Add _Py_LegacyLocaleDetected and _PyCoerceLegacyLocale to
pylifecycle.h (GH-4134)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
Given that the automated cherry-pick failed, I'd consider a 3.6 backport nice
to have, but definitely not essential.
My rationale for that is that "from __future__ import unicode_literals" makes
it fairly easy to stum
Nick Coghlan <ncogh...@gmail.com> added the comment:
Serhiy's PR avoids the cryptic BytesWarning on Py3 while minimising the
overhead of the new typecheck, so I've closed Berker's PR in favour of that one
(which now has approved reviews from both Brett and I, so Serhiy will merge it
whe
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'm fine with the approach in the latest version of the PR - it does make "from
x import y" slightly slower due to the extra error checking, but folks should
be avoiding doing that in performance critical loops or functions a
Nick Coghlan <ncogh...@gmail.com> added the comment:
We could still use some more comprehensive test cases for the env var handling
and the way that interacts with the command line settings, but the merged PR
includes at least a rudimentary check for the four that directly affect
sys
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset d7ac06126db86f76ba92cbca4cb702852a321f78 by Nick Coghlan in
branch 'master':
bpo-31845: Fix reading flags from environment (GH-4105)
https://github.com/python/cpython/commit/d7ac06126db86f76ba92cbca4cb702852a
Change by Nick Coghlan <ncogh...@gmail.com>:
--
keywords: +patch
pull_requests: +4075
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nick Coghlan <ncogh...@gmail.com>:
--
assignee: -> ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31845>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
Huh, it appears the tests for these features are relying solely on the command
line options, and not checking that the environment variables are also setting
the flags properly. We should be able to account for that omission with a
Nick Coghlan <ncogh...@gmail.com> added the comment:
+1 from me for dropping these, and noting which modules were affected in the
Porting section of the 3.7 What's New (I'd be surprised if anyone was depending
on them existing, but it doesn't hurt to mention it, and may help if s
Nick Coghlan <ncogh...@gmail.com> added the comment:
For the wording fix, since it's just a trivial docs update, we can go ahead and
fix it without an issue reference from the PRs.
As far as the API goes, I do want to support "static Py_tss_t my_tss_key =
Py_tss_NEEDS_INIT;"
Nick Coghlan <ncogh...@gmail.com> added the comment:
When I rejected that approach previously, it hadn't occurred to me yet that the
write-through proxy could write through to both the frame state *and* the
regular dynamic snapshot returned by locals().
The current design came from
Nick Coghlan <ncogh...@gmail.com> added the comment:
No, as locals() never returns the write-through proxy in the latest version of
the PEP - it only ever returns the dynamic snapshot namespace (retrieving it
from the proxy if necessary).
To get access to the write-through proxy in
Nick Coghlan <ncogh...@gmail.com> added the comment:
I rewrote the PEP based on the latest iteration of the design concept:
https://github.com/python/peps/commit/9a8e590a523bdeed0598084a0782fb07fc15dfc0
(That initial commit has some minor errors in it that I've already fixed, so
Nick Coghlan <ncogh...@gmail.com> added the comment:
Adding a couple of Red Hat folks to the nosy list, as even though this was
originally reported for Windows, the reproducers show that it's a
cross-platform issue.
tzickel would you mind signing the Python CLA and turning your
Nick Coghlan <ncogh...@gmail.com> added the comment:
Yeah, that one I definitely think could be improved. Could you file a separate
RFE suggesting that we update sys.path[0] based on __main__.__spec__.origin
after we look up __main__.__spec__?
That way it will only stay as the c
Nick Coghlan <ncogh...@gmail.com> added the comment:
Is there a relevant discrepancy other than __file__ sometimes being absolute?
If code wants to be certain that __file__ is relative to the current directory,
they need to run it through os.relpath() - there's no requi
Nick Coghlan <ncogh...@gmail.com> added the comment:
Right, the cases we were aiming to cover were:
- C variable declarations ("static Py_tss_t tss_key = Py_tss_NEEDS_INIT;")
- dynamic allocation with PyThread_tss_alloc
- resetting a key back to the uninitialised state with PyT
Nick Coghlan <ncogh...@gmail.com> added the comment:
Stefan: I'd expect so, but that's best covered by a new RFE and an associated
PR (I'm not sure what you mean from the text description, but I assume it will
be obvious as C code)
--
___
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'd personally be happy enough if the infinite iterators implemented
__length_hint__() as always raising TypeError so the machine-breaking cases of
incremental consumption of ever-increasing amounts of memory were blocked - I
was sugg
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thanks for the fix!
--
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:
To put this another way: I see an uninterruptible infinite loop as a data loss
bug on par with a segfault, since there's no graceful way to terminate the
process and allow cleanup code to run.
For segfaults, we're willing to tolerat
Nick Coghlan <ncogh...@gmail.com> added the comment:
Defensive coding and the complications it brings is a fact of life when
providing a widely used platform.
Sure, we're free to say "We don't care about minor user experience irritations
like Ctrl-C not always being reliable, u
Nick Coghlan <ncogh...@gmail.com> added the comment:
Just confirming that the locals() vs frame.f_locals distinction also exists in
the C API: the former is PyEval_GetLocals() (which implicitly ensures the
snapshot is up to date), while the equivalent of the latter is direct access to
Nick Coghlan <ncogh...@gmail.com> added the comment:
Err, I phrased that last sentence really badly.
I meant that if Guido *hasn't* been following this ticket closely, he's more
likely to ask for clarification if PEP 558 proposes a semantic change based on
the discussion here w
Nick Coghlan <ncogh...@gmail.com> added the comment:
Guido: any proposed semantic changes for CPython will eventually make their way
through PEP 558 (and potentially a competing PEP if someone else is
sufficiently keen on the idea of making non-tracing mode behave the same way as
tracin
Nick Coghlan <ncogh...@gmail.com> added the comment:
Note that we're currently looking into this as something that could be
potentially addressed by PEP 558 and any related changes to the way that
function locals interact with trace hooks:
https://bugs.python.org/issue30744#msg
Nick Coghlan <ncogh...@gmail.com> added the comment:
The current pdb misbehaviour when navigating the stack is indeed a valid
argument in favour of allowing immediate write-through from trace functions for
regular local variables as well - I don't recall reading that bug report when
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue9633>
___
__
Nick Coghlan <ncogh...@gmail.com> added the comment:
Yep, my current goal is to see if I can come up with a surgical fix that solves
the established problem with the bad interaction between cells and trace
functions without any unintended consequences for either CPython or other
interp
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'm marking this as documentation issue for now, as the operators that
literal_eval allows are solely those where constant folding support is needed
to correctly handle complex and negative numbers (as noted in the original
Nick Coghlan <ncogh...@gmail.com> added the comment:
Aye, I think that check would make the most sense, since the bytecode
invalidation check is "_r_long(raw_timestamp) != source_mtime" (to allow for
things like version control operations that send source timestamps bac
Nick Coghlan <ncogh...@gmail.com> added the comment:
OK, I'll head down the path of creating a new procedural PEP to supersede PEP
411 (I'll try to get the locals() semantic clarification PEP out of the way
first, though).
I'll make "Where to put the feature flags?" an open
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'll also note there's a simpler reason the namespace object exposed at the
function level can't just be a write-through proxy for the underlying frame:
references to frame.f_locals may outlive the frame backing it, at which point
we
Nick Coghlan <ncogh...@gmail.com> 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
implement
Nick Coghlan <ncogh...@gmail.com> 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 bypas
Nick Coghlan <ncogh...@gmail.com> 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
fro
Nick Coghlan <ncogh...@gmail.com> 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 s
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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 writte
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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-provi
Nick Coghlan <ncogh...@gmail.com> 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 __
Nick Coghlan <ncogh...@gmail.com> 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. Aft
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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
releas
Nick Coghlan <ncogh...@gmail.com> 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 tracke
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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 th
Nick Coghlan <ncogh...@gmail.com> 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 ne
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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,
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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 consistent
Nick Coghlan <ncogh...@gmail.com> 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 delibe
Nick Coghlan <ncogh...@gmail.com> 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 tracke
Nick Coghlan <ncogh...@gmail.com> 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 thir
New submission from Nick Coghlan <ncogh...@gmail.com>:
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
Nick Coghlan <ncogh...@gmail.com> 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 -&
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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: op
Nick Coghlan <ncogh...@gmail.com> 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 whe
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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
Nick Coghlan <ncogh...@gmail.com> 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 adju
Change by Nick Coghlan <ncogh...@gmail.com>:
--
stage: backport needed -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Nick Coghlan <ncogh...@gmail.com> 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/cpython/
Nick Coghlan <ncogh...@gmail.com> 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 <rep...@
Nick Coghlan <ncogh...@gmail.com> 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/
Nick Coghlan <ncogh...@gmail.com> added the comment:
Aye, that's exactly what I did.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Nick Coghlan <ncogh...@gmail.com> 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 <ncogh...@gmail.com> 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 -&
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:
- some
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:
And done - thanks for the report and PRs, Igor!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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/cf7197ae43767c4346864e5b41246f628edd9b51
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 needed
versi
Nick Coghlan added the comment:
New changeset 9adda0cdf89432386b7a0a6199b580d287a1 by Nick Coghlan (Igor
Filatov) in branch 'master':
bpo-31351: Set return code in ensurepip when pip fails (GH-3626)
https://github.com/python/cpython/commit/9adda0cdf89432386b7a0a6199b580d287a1
Nick Coghlan added the comment:
3.4 and 3.5 are in security fix only mode now, so the change won't be
backported there. However, it will be applicable to 2.7, so I've updated the
impacted version list accordingly.
Igor's suggested approach in the PR looks reasonable to me as a first step
Nick Coghlan added the comment:
We had the quirks of import related threading deadlocks documented for a long
time, not as a promise, but as a debugging aid (and a recommendation for "don't
do that").
I'd see this as being similar: we'd document that if you're using the _thre
Nick Coghlan added the comment:
Aye, the "C.__new__" example omitting the first arg was just an error in that
example.
And that's a good point about the current "object.__init__()" error message
actually being incorrect, since the *methods* each take exactly one a
Nick Coghlan added the comment:
I filed issue 31527 as a follow-up issue to see whether or not it might be
possible to amend the way these custom errors are generated to benefit from the
work that has gone into improving the error responses from
PyArg_ParseTupleAndKeywords
Nick Coghlan added the comment:
Adding a dependency on issue 31506, as this shouldn't be tackled until those
simpler amendments are resolved.
--
dependencies: +Improve the error message logic for object_new & object_init
___
Python tracker
New submission from Nick Coghlan:
object_new and object_init currently use their own argument checking logic, and
hence haven't benefited from the error reporting enhancements in
PyArg_ParseTupleAndKeywords
Compare:
>>> str(1, 2, 3, 4, 5, x=1)
Traceback (most recent call last
Nick Coghlan added the comment:
One place where this came up recently is in working out precisely how a
Python-level subinterpreter API will interact with the threading API:
https://mail.python.org/pipermail/python-dev/2017-September/149566.html
That said, I do agree with Tim that the status
Nick Coghlan added the comment:
Reopening, as I was a little hasty with the merge button: the merged PR *also*
changed the `__init__` error message to drop the method name, but I don't think
that's what we want.
I'm also wondering if we should change the up-call case to *always* report
Changes 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 added the comment:
New changeset a6c0c0695614177c8b6e1840465375eefcfee586 by Nick Coghlan (Serhiy
Storchaka) in branch 'master':
bpo-31506: Improve the error message logic for object.__new__ and
object.__init__. (GH-3650)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
That said, bringing over my overall comment from the PR review:
I think the number of additional changes needed in the test suite and the
standard library highlights the compatibility restoration busy-work risks of
actually making this change:
- while
Nick Coghlan added the comment:
For write-backs: no, since the interpreter will still write those values back
into the destination cell
For locals display: no, since nothing changes for the handling of fast locals
For closure display: yes as, by default, debuggers will now print the closure
Nick Coghlan added the comment:
Those would both report "C() takes no parameters" without further enhancements
(which would be out of scope for this issue).
The proposed improvement here isn't "Let's make the error message exactly
correct in all cases" (that's probably imp
Nick Coghlan added the comment:
Specifically this message, where the unwritten rationale is to offer
behavioural consistency across the builtin types that know their own name and
include it in their current repr() output:
https://mail.python.org/pipermail/python-ideas/2011-October/012464.html
Nick Coghlan added the comment:
For this issue, I'm not proposing to make any change other than to solve the
specific problem reported in the blog post: when the method itself isn't
overridden, then the error message should report the name of the most derived
class, not "object"
Nick Coghlan added the comment:
Fortunately, the logic is already well encapsulated: there's a "if (excess_args
&& (case A || case B)) {... report error ...}" check at the start of each of
object_new and object_init, where "case A" = "the other function in the
1001 - 1100 of 6264 matches
Mail list logo
