New submission from Nick Coghlan :
test_curses fails for me by default (running on Fedora 35 in KDE's Konsole):
```
[ncoghlan@thechalk cpython]$ echo $TERM
xterm-256color
[ncoghlan@thechalk cpython]$ ./python -m test -u curses test_curses
0:00:00 load avg: 0.88 Run tests sequentially
0:
Change by Nick Coghlan :
--
pull_requests: +30078
pull_request: https://github.com/python/cpython/pull/31987
___
Python tracker
<https://bugs.python.org/issue44
Change by Nick Coghlan :
--
pull_requests: +30113
pull_request: https://github.com/python/cpython/pull/32024
___
Python tracker
<https://bugs.python.org/issue44
Nick Coghlan added the comment:
The import system is already complex, so I think the hesitation about allowing
arbitrary Path-like objects is warranted. (For example: are importlib's caching
semantics really valid for *arbitrary* path-like objects? An object can be
path-like without
Nick Coghlan added the comment:
On the historical front, wraps & update_wrapper were only designed to handle
true wrapper functions (i.e. those that don't change the calling signature).
For anything else (including partial), I considered it unlikely that the doc
string would
Nick Coghlan added the comment:
Moving the invariant bits would certainly make sense.
As Victor notes, though, some things (like whether to install the signal
handlers) should be different.
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
Seems reasonable to me, but I think a full implementation would want to throw
an error for keyword args that don't already exist as context attributes
(otherwise typos would fail silently)
--
___
Python tr
Nick Coghlan added the comment:
I agree the status quo has its benefits. However, it has the distinct downside
that because each interpreter has its own storage for copied settings, other
code has to assume the settings *might* be different in each interpreter, even
if they're curr
Nick Coghlan added the comment:
I'm not, so I assume this got cleaned up somewhere along the way.
--
resolution: -> out of date
stage: needs patch -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.pyth
Nick Coghlan added the comment:
Mark's suggested frame stack API makes sense to me, but being able to get/set
specific values through the full frame API seems like it would be useful even
if the lower level API existed - if we don't get one of the proxy PEPs in shape
to land in 3
Change by Nick Coghlan :
--
pull_requests: +30342
pull_request: https://github.com/python/cpython/pull/32281
___
Python tracker
<https://bugs.python.org/issue44
Nick Coghlan added the comment:
Core dev forum thread:
https://discuss.python.org/t/proposal-rename-pyinterpreterframe-struct-as-py-framedata/14213
The conclusion from the forum thread and associated PRs was that any of the
further renaming proposed didn't provide sufficient addit
New submission from Nick Coghlan :
While working on the first PR for bpo-44800 I provoked an obscure failure in
PyImport_ImportModule by making PyEval_GetGlobals set an exception when
returning NULL (as PyEval_GetLocals has done since bpo-18408 was implemented
for Python 3.4).
This ticket
Nick Coghlan added the comment:
Core dev forum thread for the C API question:
https://discuss.python.org/t/subtle-c-api-discrepancy-pyeval-getlocals-vs-pyeval-getglobals-with-no-python-frame/14797
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
New changeset 124227c95f310d2ecd4b567271ab1919fc7000cb by Nick Coghlan in
branch 'main':
bpo-44800: Document internal frame naming conventions (GH-32281)
https://github.com/python/cpython/commit/124227c95f310d2ecd4b567271ab19
Nick Coghlan added the comment:
The outcome of the python-dev discussion was that we agreed to switch to
raising a plain SyntaxError, as that's what we do everywhere else that this
kind of problem comes up (e.g. conflicts between global and nonlocal
declarations, or between thos
Nick Coghlan added the comment:
Even though it doesn't fully resolve this crash, I'd still like us to consider
reverting the change to allow "continue" in try/finally blocks.
It doesn't seem to have a compelling practical motivation behind it (beyond the
fact tha
Nick Coghlan added the comment:
New changeset 5dbe0f59b7a4f39c7c606b48056bc29e406ebf78 by Nick Coghlan in
branch 'master':
bpo-37757: Disallow PEP 572 cases that expose implementation details (GH-15131)
https://github.com/python/cpython/commit/5dbe0f59b7a4f39c7c606b48056bc2
Change by Nick Coghlan :
--
pull_requests: +15178
pull_request: https://github.com/python/cpython/pull/15491
___
Python tracker
<https://bugs.python.org/issue37
Nick Coghlan added the comment:
New changeset 6ca030765db49525f16b8fabff4153238148b58d by Nick Coghlan in
branch '3.8':
[3.8] bpo-37757: Disallow PEP 572 cases that expose implementation details
(GH-15491)
https://github.com/python/cpython/commit/6ca030765db49525f16b8fabff4153
Nick Coghlan added the comment:
Merged for 3.8b4 after Emily's review.
Thanks to all involved in the PEP update and change discussion!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python t
Nick Coghlan added the comment:
Thank you Pablo!
Even having seen your fix, it still took me a couple of rescans of the original
PR to figure out exactly how I'd broken it in the first place (refactoring to
call an existing function without noticing that the replaced code included an
Change by Nick Coghlan :
--
pull_requests: +15269
pull_request: https://github.com/python/cpython/pull/15593
___
Python tracker
<https://bugs.python.org/issue37
Nick Coghlan added the comment:
Reviewing the PR post-merge, I'm pretty sure this has introduced a
double-decrement bug due to the original code being hard to read (the error
cases did the decrement inside the helper function, while the success case did
it in the calling function).
Nick Coghlan added the comment:
Reviewing all the code that touches recursion_depth (both in the symtable and
in the thread state), I'm not seeing any sanity checks that ensure our
increments and decrements *balance*.
So I'm going to add one to PySymTable_B
Nick Coghlan added the comment:
New changeset 06145230c833c3db5dab8858e11bcd550a37c57f by Nick Coghlan in
branch 'master':
bpo-37947: Avoid double-decrement in symtable recursion counting (GH-15593)
https://github.com/python/cpython/commit/06145230c833c3db5dab8858e11bcd
Nick Coghlan added the comment:
Yes, this is deliberate. From the run_module documentation: "__name__ is set to
run_name if this optional argument is not None, to mod_name + '.__main__' if
the named module is a package and to the mod_name argument otherwise."
This allo
Change by Nick Coghlan :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37941>
___
___
Python-bugs-list
Nick Coghlan added the comment:
Good point regarding the heuristic: it would need to take the requested module
name into account to be correct.
* check if the requested module was found relative to the current directory
(can be worked out from __main__.__spec__ and the current working
Nick Coghlan added the comment:
We never actually coded a reproducer for this, but if we had, it would have
been a crash bug.
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
It isn't the simple case where the auto-detection idea concerns me, it's
decorator stacking cases like:
@outer
@magic_detection
@inner_forces_async
def sync_native_api():
...
(With the original asyncio.coroutine being one ex
Nick Coghlan added the comment:
This is a documentation bug, as the current behaviour is as intended, but the
documented equivalence doesn't hold for generator functions: for a generator
function, the CM will only be applied when the generator is instantiated,
whereas the inline co
Nick Coghlan added the comment:
The query in #37743 highlights that generator functions and other wrapped
iterator factories actually face a similar problem: they need the function body
to contain "yield from wrapped(*args, **kwargs)" if the CM is going to be
closed after th
Nick Coghlan added the comment:
Reviewing this again now, I think my previous naming suggestion is problematic,
as it encourages conflating two different concepts that use similar syntax:
* collecting arbitrary positional parameters in a tuple (VAR_POSITIONAL) or
arbitrary keyword
Nick Coghlan added the comment:
There is also the draft test case at https://github.com/ncoghlan/cpython/pull/2
That needs updating to account for the eval loop changes since I last worked on
it, though. (I think that conflict may also be keeping the bots from running,
even after I updated
Nick Coghlan added the comment:
So we'd be going with a naming convention where "VAR" corresponds to the star
syntax, and whether it means packing or unpacking, or refers to arguments or
parameters is context dependent?
I could definitely support that, given that the am
Nick Coghlan added the comment:
There is one, it just isn't public: runpy._run_module_as_main.
It's a private API that the -m switch implementation calls, and was introduced
after the original runpy.run_module was found not to offer everything the
switch needed.
It isn't po
Nick Coghlan added the comment:
New changeset bdd6945d4dbd1fe6a7fcff95f7d6908db7d791a1 by Nick Coghlan (Xtreak)
in branch 'master':
bpo-33095: Add reference to isolated mode in -m and script option (GH-7764)
https://github.com/python/cpython/commit/bdd6945d4dbd1fe6a7fcff95f7d690
Nick Coghlan added the comment:
It's also not unique to with statements - it applies to all finally clauses.
The longstanding workaround when deterministic cleanup is absolutely critical
has been to run the "real" application in a subthread, and devote the main
threa
Nick Coghlan added the comment:
New changeset 9c2682efc69568e1b42a0c1759489d6f2e3b30ea by Nick Coghlan (Ram
Rachum) in branch 'master':
bpo-37937: Mention frame.f_trace in sys.settrace docs (GH-15439)
https://github.com/python/cpython/commit/9c2682efc69568e1b42a0c1759489d
Nick Coghlan added the comment:
Thanks for the PR, Ram, and the initial review, Serhiy.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8
___
Python tracker
<https://bug
Nick Coghlan added the comment:
The hidden _config_version field wasn't in the accepted PEP.
Both it and struct_size should be removed, as we don't support updating an
embedded Python runtime to a new X.Y.0 release without rebuilding the embedding
application.
--
nosy:
New submission from Nick Coghlan :
(Nosy list is RM, PEP 587 BDFL-Delegate, PEP 587 author)
Filing as a release blocker, given that I don't think we should ship rc1 until
consensus has been reached on the last minute changes to the PEP 587
configuration API.
Thread at
Nick Coghlan added the comment:
(I'm currently working a PR for this that Victor can review)
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +16084
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/16496
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
Just noting for the record that the reason a new warning wasn't needed here is
because there is already a general "No compatibility guarantees" warning for
the entire test package: https://docs.python.org/3/library/test.html
Thanks for gettin
Nick Coghlan added the comment:
Agreed. I've also added PEP 587 to the issue title to make the connection to
that PEP more obvious.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
title: PEP 432: Redesign the interpreter startup seque
Nick Coghlan added the comment:
There are a couple of cases that the C locale coercion tests skip because I
don't (or didn't) know what they *should* do:
*
https://github.com/python/cpython/blob/24dc2f8c56697f9ee51a4887cf0814b6600c1815/Lib/test/test_c_locale_coercion.py#L262
Nick Coghlan added the comment:
(Removed the patch keyword, as the linked PR was for an old change that didn't
cover the remaining test issues)
--
___
Python tracker
<https://bugs.python.org/is
Nick Coghlan added the comment:
The benefit offered by the parent local scoping was that it made assignment
expressions usable as a straightforward way to implement comprehension-based
accumulators where you actually do want access to the final value after the
comprehension completes (for
Nick Coghlan added the comment:
Yes, this is a design flaw in the Python 2 import system - it derives
`__package__` from `__name__` the first time it needs the information and
`__package__` isn't already set.
The problem was fixed for the Python 3 series by way of PEP 451, which
Nick Coghlan added the comment:
I think that's a valid point regarding sys.argv[0] - it's the import system and
code introspection that wants(/needs) absolute paths, whereas sys.argv[0] gets
used in situations (e.g. usage messages) where we should retain whatever the OS
gave us,
Nick Coghlan added the comment:
Another interesting question this raises is whether type.__setattr__ should be
checking for values that have `__set_name__` methods defined and calling those
methods automatically.
Unfortunately, I think the answer to that is "If we'd thought of
Nick Coghlan added the comment:
Regarding the "attrname" property idea: unfortunately, that won't work, as
`__set_name__` doesn't just provide the attribute name, it also provides a
reference to the class itself.
cached_property needs both pieces of information, not jus
Nick Coghlan added the comment:
After writing my previous comment, I double-checked the code, and
cached_propery is actually one of the cases where a simple "self.attrname =
'age3'" *will* do the right thing, as cached_property never checks the class
information.
Th
Nick Coghlan added the comment:
This change isn't in Python 3.8 though, it's only in Python 3.9 (the PR merge
date is after the beta 1 branch date).
Unless it was backported in a Python 3.8 PR that didn't link back to this issue
or the origina
New submission from Nick Coghlan :
In the SC submission ticket for PEP 642
(https://github.com/python/steering-council/issues/43 ), Guido indicated he was
in favour of the more explicit pattern matching AST changes suggested in that
PEP.
This ticket covers adapting the pattern matching
Nick Coghlan added the comment:
Agreed. I had wanted the AST to be part of the PEPs specifically *because* it's
a public API, but didn't check until today whether or not the original PEP 634
implementation had been merged as-is, or with a cleaned up AST definition.
https://
Nick Coghlan added the comment:
It's specifically the definition of "match_case" in the AST that is affected:
match_case = (pattern pattern, expr? guard, stmt* body)
pattern = MatchAlways
| MatchValue(expr value)
| MatchConstant(constant value)
Nick Coghlan added the comment:
https://www.python.org/dev/peps/pep-0642/#representing-patterns-explicitly-in-the-abstract-syntax-tree
covers the rationale for why it is potentially problematic to reuse expression
nodes for match patterns: it doesn't semantically align with the fact
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +24241
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25521
___
Python tracker
<https://bugs.python.org/issu
Change by Nick Coghlan :
--
stage: patch review -> needs patch
___
Python tracker
<https://bugs.python.org/issue43892>
___
___
Python-bugs-list mailing list
Un
Nick Coghlan added the comment:
The draft PR moved because I messed up the previous branch name:
https://github.com/ncoghlan/cpython/pull/9/files
It's to the point where everything except symtable.c compiles.
I put an initial skeleton of a validator in, but only enough to check tha
Change by Nick Coghlan :
--
priority: normal -> critical
___
Python tracker
<https://bugs.python.org/issue43897>
___
___
Python-bugs-list mailing list
Un
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue43897>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I've removed the "?" from the end attributes for pattern nodes.
The draft PR branch now compiles, but I've clearly made a mistake somewhere as
it segfaults when trying to compile test_patma.py.
--
__
Nick Coghlan added the comment:
My proposed MatchConstant node name was bothering me, as most constants are
actually matched by equality in MatchValue, the same way variables are.
So I'm switching my proposed name for that node to be MatchSingleton, since
that better reflects th
Nick Coghlan added the comment:
Segfaults are fixed (I had a couple of cases where I wasn't checking for NULL,
and another where I was looking up MatchMapping attributes on a MatchClass
node).
test_patma passes except for test cases 240, 241, and 242, which look like
genuine regres
Nick Coghlan added the comment:
To get the "0+0" matching case rejected again I had to flesh out a bit more of
the AST validator. This initial piece of the validator replaces the previously
pattern-matching-specific AST optimisation code that refused to fold BinOp
expressions th
Nick Coghlan added the comment:
https://github.com/ncoghlan/cpython/pull/9/commits/54940a3817df3046da3f9c51d4d426a73b2ec786
implements Brandt's suggestion of disallowing NULL keys in MatchMapping and
instead passing in an explicit "rest" identifier to capture the extra
Nick Coghlan added the comment:
Setting clear timing expectations, given beta is so close: I'm not expecting to
have time to finish the unparser work over the weekend, but I do expect to have
time to finish it on Monday evening my time (U
Nick Coghlan added the comment:
Interesting idea - I had missed that you were suggested "identifier*" for the
cls node. It's simple enough to check for Name-or-Attribute in the AST
validator though, and sticking with a standard expr_ty node means getting a lot
of standard
Nick Coghlan added the comment:
Working on the unparser picked up an inconsistency I had previously missed:
aside from named expressions, "target" attributes in the AST are generally full
expression subnodes, rather than identifier attributes. Identifier attributes
on nodes are
Change by Nick Coghlan :
--
pull_requests: +24305
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25585
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
PR against the main repo is now up: https://github.com/python/cpython/pull/25585
A couple of things in the unparser tripped me up (ast_unparse.c only handles
annotation expressions, the way ast._Unparser.visit() is defined means
NodeVisitor.generic_visit
Nick Coghlan added the comment:
PR is green now, and I don't have any further changes I want to make, so
Brandt, please feel free to merge if you're happy with the proposed AST nodes,
and the way I've gone about implementing them.
If you'd like some adjustments, it pro
Change by Nick Coghlan :
--
stage: patch review -> commit review
___
Python tracker
<https://bugs.python.org/issue43892>
___
___
Python-bugs-list mai
Change by Nick Coghlan :
--
assignee: ncoghlan -> brandtbucher
___
Python tracker
<https://bugs.python.org/issue43892>
___
___
Python-bugs-list mailing list
Un
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<https://bugs.python
Change by Nick Coghlan :
--
pull_requests: -24157
___
Python tracker
<https://bugs.python.org/issue41682>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nick Coghlan :
--
stage: patch review -> needs patch
___
Python tracker
<https://bugs.python.org/issue41682>
___
___
Python-bugs-list mailing list
Un
Nick Coghlan added the comment:
Another instance at
https://github.com/python/cpython/pull/25585/checks?check_run_id=2447701034
I unlinked the previously linked PR, as that looked to be for bpo-43539 rather
than this issue.
--
nosy: +ncoghlan
Nick Coghlan added the comment:
After the next docs build, the documentation for the explicit AST nodes should
be available https://docs.python.org/dev/library/ast.html#pattern-matching
--
resolution: -> fixed
stage: commit review -> resolved
status: open -&g
Nick Coghlan added the comment:
New changeset 59af59c2dfa52dcd5605185263f266a49ced934c by Erlend Egeberg
Aasland in branch 'main':
bpo-42972: Fully support GC for pyexpat, unicodedata, and dbm/gdbm heap types
(GH-26376)
https://github.com/python/cpyt
Nick Coghlan added the comment:
bpo-40816 took the much simpler approach of introducing a separate
contextlib.AsyncContextDecorator class.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Add missed AsyncContextDecorator to context
New submission from Nick Coghlan :
Backporting the latest contextlib module and test suite to contextlib2, I ran
into a couple of CI failures on PyPy3.
Investigation showed that a couple of the new test cases were assuming the use
of a refcounted GC. One could be fixed by switching to using
Change by Nick Coghlan :
--
versions: +Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue44515>
___
___
Python-bugs-list mailin
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +25486
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/26910
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
I've updated PEP 558 with a reference back to this ticket as additional
motivation (the update also addresses several of the fragility concerns that
Mark raised): https://github.com/python/peps/pull/1787
There's still work to be done to bring the
New submission from Nick Coghlan :
The fast locals proxy implementation for PEP 558 used the existing
MappingProxyType implementation as a starting point.
This meant I noticed the following code in the mapping proxy comparison
implementation:
==
static PyObject
Nick Coghlan added the comment:
I stumbled across this independently in bpo-44596, but missed this existing
report due to the specific word I was looking for (encapsulation).
In addition to the comparison operand coercion, there's now another access
option through the `__ror__` method.
Nick Coghlan added the comment:
New changeset b494685b2548489efcc66993cc6c13b027ce3b26 by Steven Hsu in branch
'main':
bpo-44561: Update hyperlinks in Doc/distributing/index.rst (#27032)
https://github.com/python/cpython/commit/b494685b2548489efcc66993cc6c13b027ce3b26
-
Change by Nick Coghlan :
--
stage: patch review -> backport needed
___
Python tracker
<https://bugs.python.org/issue44561>
___
___
Python-bugs-list mai
Nick Coghlan added the comment:
Delegating operations to the underlying mapping is still OK, all we're wanting
to bypass is the operand coercion dances in abstract.c and object.c that may
expose the underlying mapping to the *other* operand.
We don't want to implicitly copy thou
Nick Coghlan added the comment:
I suspect the only reason the dis CLI isn't documented is because it's been
around for so long (22 years!) that nobody previously noticed it was missing:
https://github.com/python/cpython/commit/1fdae12c93246fcf4abbf882ba08df789070dfcc
Folks t
New submission from Nick Coghlan :
When merging the bpo-44590 changes into my PEP 558 implementation branch, I
found it very hard to follow when the code was referring to the new interpreter
frames rather than the existing Python frame objects that were historically
used for both execution
Change by Nick Coghlan :
--
dependencies: +Create frame objects lazily when needed
___
Python tracker
<https://bugs.python.org/issue44800>
___
___
Python-bug
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue44800>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan added the comment:
As a side effect of working on this, I noticed some changes that are needed to
adapt the GDB integration hooks to the new frame state layout.
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.
Change by Nick Coghlan :
--
nosy: +ncoghlan
nosy_count: 3.0 -> 4.0
pull_requests: +26041
pull_request: https://github.com/python/cpython/pull/27525
___
Python tracker
<https://bugs.python.org/issu
1201 - 1300 of 6301 matches
Mail list logo
