Nick Coghlan 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 really do
Nick Coghlan 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 quest
Nick Coghlan 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 backwards).
A test for that could
Nick Coghlan 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
post):
```
>>> dis
Nick Coghlan 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
interpreters.
That means the
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue9633>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan 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
Xavier first linked to i
Nick Coghlan 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#msg3
Nick Coghlan 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
tracing mode), so ignoring the
Nick Coghlan 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 without adequately justif
Nick Coghlan 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
frame->f_locals (and i
Nick Coghlan 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, users should just
Nick Coghlan 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 tolerate them, but we
Nick Coghlan added the comment:
Thanks for the fix!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan 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 suggesting on python-
Nick Coghlan 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)
--
___
Python
Nick Coghlan 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 PyThread_tss_delete
The probl
Nick Coghlan 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 requirement for
implementations one way o
Nick Coghlan 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 current directory if the module
Nick Coghlan 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 patch into a PR
on G
Nick Coghlan 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
check the latest version i
Nick Coghlan 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 Python level code, you have to
Nick Coghlan 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 asking myself "W
Nick Coghlan 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;" in third party ex
Nick Coghlan 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 someone is
tryin
Nick Coghlan 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
single new test in
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue31845>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +4075
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31845>
___
___
Py
Nick Coghlan 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/d7ac06126db86f76ba92cbca4cb702
Nick Coghlan 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.flags without any tricky
Nick Coghlan 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 anyway.
It would be n
Nick Coghlan 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
when he&#
Nick Coghlan 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 stumble over the 2.7 varian
Nick Coghlan 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/cpyt
Nick Coghlan added the comment:
Thanks for the patch!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan 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 tests for the SystemError
Nick Coghlan 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
separately from the assessments
New submission from Nick Coghlan :
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 summarises replacement module
Change by Nick Coghlan :
--
stage: -> needs patch
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue31898>
___
___
Python-bugs-list
New submission from Nick Coghlan :
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 nominate parti
Nick Coghlan added the comment:
https://bugs.python.org/issue31899 is a follow-up issue to discuss whether or
not it would make sense to expand these recommendations to cover explicit
compatibility testing against these libraries for CPython updates
Nick Coghlan added the comment:
Hmm, I don't think calling Py_Finalize in any interpreter other than the main
one is actually defined at all, so I'm inclined to just make it an error,
rather than trying to figure out how it should work. It would then be up to the
embedding appl
Nick Coghlan added the comment:
For the main interpreter, Py_Finalize should be destroying all other
subinterpreters as one of the first things it does, so if we're *not* currently
doing that, it would make sense to fix it as part of Eric's subinterp
Nick Coghlan added the comment:
I guess we allow an unhandled SystemExit in a child thread to propagate to (and
hence terminate) the main thread, so allowing a Py_Finalize call in a
subinterpreter to terminate the main interpreter would be comparable to that.
My main rationale for *requiring
Nick Coghlan added the comment:
As part of this, a new subsection would be added to
https://docs.python.org/devguide/stdlibchanges.html to document the process for
adding new packages to the recommended packages list: propose them for standard
library inclusion, and while "No" is
Nick Coghlan added the comment:
Thinking about it further, this list is actually going to be version
independent, suggest it may actually belong somewhere outside the main
documentation.
The Developer's Guide may be a reasonable stopgap measure until there's a
better option avai
Nick Coghlan added the comment:
New changeset e8b19656396381407ad91473af5da8b0d4346e88 by Nick Coghlan
(stratakis) in branch 'master':
bpo-23699: Use a macro to reduce boilerplate code in rich comparison functions
(GH-793)
https://github.com/python/cpyt
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
In https://mail.python.org/pipermail/python-ideas/2017-October/047599.html,
Guido suggested managing this as an occasionally updated Informational PEP
(somewhat akin to PEP 394), and I think that will actually work fairly well:
* it clearly gives the
Nick Coghlan added the comment:
Cross-linking to the work-in-progress RFE that introduced the error:
https://bugs.python.org/issue22257
--
___
Python tracker
<https://bugs.python.org/issue31
Nick Coghlan added the comment:
Bug report (since resolved) that highlighted our general lack of test coverage
for the interactions between environment variable based configuration and
command line based configuration: https://bugs.python.org/issue31845
This work revealed the absence, since
Change by Nick Coghlan :
--
pull_requests: +4248
___
Python tracker
<https://bugs.python.org/issue22257>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nick Coghlan :
--
pull_requests: +4249
___
Python tracker
<https://bugs.python.org/issue31845>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
New changeset 1b46131ae423f43d45947bb48844cf82f6fd82b8 by Nick Coghlan in
branch 'master':
bpo-22257: Mention startup refactoring in What's New (GH-4286)
https://github.com/python/cpython/commit/1b46131ae423f43d45947bb48
Nick Coghlan added the comment:
New changeset 1b46131ae423f43d45947bb48844cf82f6fd82b8 by Nick Coghlan in
branch 'master':
bpo-22257: Mention startup refactoring in What's New (GH-4286)
https://github.com/python/cpython/commit/1b46131ae423f43d45947bb48
Nick Coghlan added the comment:
Starting to make some progress on an implementation, and it occurs to me that
if this approach does work out, it should make Python level trace functions
*much* faster.
Right now, the call to the Python function in call_trampoline is bracketed by
Nick Coghlan added the comment:
Right, and that's why I think we're better off focusing on the arithmetic
explanations wherever they apply. The problem is that for "x | y" and "x & y"
there's no avoiding discussing the 2's complement representati
Nick Coghlan added the comment:
Interesting - I'd never looked at how cProfile works before, and the fact it
already doesn't support the "-i" (interactive) switch makes it much simpler to
handle than the pdb case.
So from a runpy perspective, this approach gets a +1 fro
Nick Coghlan added the comment:
Issue 21862 is a related issue specifically for the cProfile module.
In that case, cProfile's command line invocation *doesn't* use the main module,
so the patch is able to just create a synthetic call to runpy.run_module as a
string and compile t
Nick Coghlan added the comment:
See issue 21862 and issue 9325 as potential use cases for this feature.
While it looks like issue 21862 (-m switch support in cProfile) can be
implemented just fine without it, this feature will be needed for the modules
that execute the given scripts directly
Change by Nick Coghlan :
--
versions: +Python 3.7 -Python 3.5
___
Python tracker
<https://bugs.python.org/issue19982>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
I added an inline comment on the PR - I think what's there now would work fine,
but I also suggested a slightly shorter and clearer (at least to me)
alternative.
--
___
Python tracker
<https://bugs.py
Nick Coghlan added the comment:
Also, based on reviewing this, I suspect the same approach would also work for
the pure Python profile module.
--
___
Python tracker
<https://bugs.python.org/issue21
New submission from Nick Coghlan :
As per the post at
https://mail.python.org/pipermail/python-dev/2017-November/150366.html, this is
an RFE to cover adding a new warning filter to the default set:
once::DeprecationWarning:__main__
This means that all deprecation warnings triggered
Nick Coghlan added the comment:
Yes - stuff just flat out breaks when Linux distros upgrade Python.
The response is "Yeah, python-dev decided years ago that they don't care about
that".
--
___
Python tracker
<https://bugs.pyt
Nick Coghlan added the comment:
(And yes, I could push this as a downstream patch to Fedora's Python packages
instead - if enough folks insist that springing breaking changes on people
without warning them that those changes coming is fine, that's wh
Nick Coghlan added the comment:
Ah, I see - yeah, that makes a lot of sense.
I've retitled the issue to make it clearer that the problem is where the
responsibility for calling atexit functions lives - currently it's in
Py_Finalize, but really it should be inside the interpreter ob
Nick Coghlan added the comment:
Sure, it's harsh, but it's still what it looks like from the outside - there's
no PEP explaining the reasoning for putting the interests of app developers
that don't want to take responsibility for their user experience ahead of thos
Nick Coghlan added the comment:
I'm currently still too annoyed to write a PEP about this - it would probably
come out in tone like the state of the unicode literals PEP before I edited it.
I just don't understand how this logic is hard: *our* primary responsibility
for deprecatio
Nick Coghlan added the comment:
Reopening this based on several years of additional experience with context
managers since I wrote https://bugs.python.org/issue10049#msg119514 when
originally closing it.
The version I'm now interested in adding is the one from
https://bugs.pytho
Nick Coghlan added the comment:
Reverting to "Needs patch", as the currently attached patch is for the "No
behaviour" variant that always returns None from __enter__().
(hniksic, would you still be willing to sign the Python CLA? If so, then your
patch could be used
Nick Coghlan added the comment:
Antoine, it's not a wishy-washy compromise, it's a compromise based on the fact
that code that has been factored out to a support module is far more likely to
have a test suite than code that's directly in __main__.
Thus the logic for the
Nick Coghlan added the comment:
Issue 30672 is potentially related here - some of the test cases are already
disabled on Mac OS X and other *BSD systems since the tests assume that C &
POSIX are aliases of each other.
I've also added Xavier to the nosy list, since the current imple
Nick Coghlan added the comment:
OK, I'd been meaning to get back to refactoring those tests anyway, so
assigning this to myself.
I'm thinking that the right way to go will be to give the test case a more
explicit model of "expected platform behaviour" (initialised in s
Nick Coghlan added the comment:
OK, I've had a couple of days to become not-annoyed about this, and given the
discovery that pytest doesn't currently enable DeprecationWarning by default
(even though the default DeprecationWarning behaviour changed more than 7 years
ago), I'm
Nick Coghlan added the comment:
Given the existing "gc.enable", "gc.disable" and "gc.isenabled" APIs, I'd
suggest calling this one "gc.ensure_disabled": it ensures the GC is disabled in
the with statement body, but only turns it back on at the
Change by Nick Coghlan :
--
pull_requests: +4322
___
Python tracker
<https://bugs.python.org/issue32002>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
The essential problem in both this issue and issue 30672 is that the tests are
currently incorporating some Linux-specific assumptions about ways to request
the "C" locale.
In https://github.com/python/cpython/pull/4369, I've taken the approach
Nick Coghlan added the comment:
Note: I'm not entirely sold on my own argument though, as I believe at least
Alpine Linux already interprets the empty locale as C.UTF-8, so it may make
more sense to use your dynamic check with both the empty string and "POSIX",
and only testin
Nick Coghlan added the comment:
Regarding "Why not revert DeprecationWarning to behaving the same as
FutureWarning?", the rationale is basically the one Brett gave on python-dev
(which was a restatement of the one that led to the change in python-dev): it's
genuinely annoy
Nick Coghlan added the comment:
As far as documentation goes, there are the amendments I'm considering:
===
exception DeprecationWarning
Base class for warnings about deprecated features. Visible by default for
APIs called from `__main__` modules and when usin
Nick Coghlan added the comment:
Antoine, I'm a user too, and this single small change will be enough to
solve *my* problems, while still addressing Guido's developer tool
usability concerns that prompted him to change the default in the first
place (see the stdlib-sig thread for mo
Nick Coghlan added the comment:
The initial draft of the PEP is up: https://www.python.org/dev/peps/pep-0565/
--
___
Python tracker
<https://bugs.python.org/issue31
Nick Coghlan added the comment:
My impression is that you've been arguing that my changes don't go far enough
(i.e. you'd prefer full reversion to the pre-2.7 behaviour), not that the
status quo is superior.
My PEP covers both why I think the status quo is problematic, and w
Nick Coghlan added the comment:
I relearned a fair bit myself in writing it - I'd completely forgotten the
original rationale was about developer tools emitting unhelpful noise (rather
than general Python applications), and that's far more persuasive than the
rationale I'
Nick Coghlan added the comment:
I also learned we need more concrete examples of useful PYTHONWARNINGS and -W
settings in the docs - I believe PEP 565 currently contains more of those than
all of our existing warnings related documentation put together :)
I'll look into that &quo
Nick Coghlan added the comment:
Reviewing the original thread yet again, you're right the original decision
wasn't specifically about developer tools (and I guess at some level I knew
that, or I wouldn't have been motivated to suggest the change to
FutureWarning's docume
Nick Coghlan added the comment:
The default command line UX of Python developer tools is also more
unambiguously python-dev's responsibility, though. That's where my own initial
line of argument for full reversion (i.e. that we should be letting app
developers manage their own stde
Nick Coghlan added the comment:
In a function call, `f(x for x in iterable)` is roughly equivalent to
`f(iter(iterable))`, not `f(*iterable)` (the genexp based equivalent of the
latter would be ``f(*(x for x in iterable))`).
Thus the base class list is no different from any other argument
Nick Coghlan added the comment:
As a user, what would I actually gain from being warned more than once per
session that a particular API I'm using is deprecated?
If I want that behaviour, I can already opt in to it by doing
"warnings.simplefilter('always')".
As thin
Nick Coghlan added the comment:
I don't think anybody consistently does proper resource management in the REPL,
so the trade-offs involved there are quite different from those for deprecation
warnings.
Assuming PEP 565 gets accepted, we'll end up with once-per-session warnings f
New submission from Nick Coghlan :
The compiler currently allows parentheses to be omitted if a generator
expression is the sole entry in a base class list:
>>> class C(x for x in []): pass
...
Traceback (most recent call last):
File "", line 1, in
Nick Coghlan added the comment:
I created https://bugs.python.org/issue32023 to explicitly cover the base class
list case, and after checking the language spec, I agree that case should be a
syntax error.
However, `@deco(x for x in [])` should *not* be a syntax error, as:
* it's a call
New submission from Nick Coghlan :
Function calls in decorators are implemented as regular function calls, and
hence permit the use of generator expressions as their sole argument without a
second pair of parentheses.
However,
https://docs.python.org/3/reference/compound_stmts.html#function
Nick Coghlan added the comment:
OK, I've filed https://bugs.python.org/issue32024 to cover the decorator syntax
discrepancy.
So I'd still prefer to restrict the patch for *this* issue to just the
genuinely ambiguous case, and leave the
unambiguous-but-inconsistent-with-the-lan
Nick Coghlan added the comment:
If limited to the original scope, this isn't a new special case, it's fixing a
bug in the implementation of the existing special case (where it's ignoring the
trailing comma when it shouldn't be).
If it hadn't been for the scope cre
Nick Coghlan added the comment:
While it doesn't necessarily need to be in this patch, something else I
recently realised (by breaking it *cough* [1]) is that the interaction between
our command line options and our environment variables isn't really clearly
defined anywhe
Nick Coghlan added the comment:
I think it's reasonable to keep this open if the problems can be reproduced
with the current 3.7 dev branch - while we've refactored a lot of things, we
haven't specifically gone memory leak hunting for the embedded case, and I'm
pretty
Nick Coghlan added the comment:
Given the symptoms (stripping 4 spaces + "pr" from the start of the line,
leaving "int " behind), it looks like we're not stripping the leading
whitespace when determining the text to include in the suggested print() call.
To reprod
Nick Coghlan added the comment:
With issue 32023 (base class lists) and 32034 (fixing the documentation for
decorator factory function calls) covering the other refinements, this
particular issue is done now.
The most recent PR is the one for issue 32023.
--
resolution: -> fi
2501 - 2600 of 6301 matches
Mail list logo
