Mark Shannon added the comment:
New changeset c3f52b4d707a78eb342372a2be00f3eb846a05b9 by Mark Shannon in
branch 'main':
bpo-44486: Make sure that modules always have a dictionary. (GH-26847)
https://github.com/python/cpython/commit/c3f52b4d707a78eb342372a2be00f3eb846a05b9
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25428
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26847
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
It is possible to create a module without a dictionary:
m = types.ModuleType.__new__(types.ModuleType)
But that is the only way to create to a module without a dict; all other means
of creating a module, both in Python and in the C API, result in a fully
Mark Shannon added the comment:
Hmm, I'm a bit puzzled by that.
Did you test with 3.10b3 or the latest build from the 3.10 branch with the fix
to https://bugs.python.org/issue44297 included?
--
___
Python tracker
<https://bugs.python.
Mark Shannon added the comment:
With the latest 3.10, I get:
File "/home/mark/test/test.py", line 13, in
next(bar().__await__(), None)
File "/home/mark/test/test.py", line 10, in bar
return [chunk async for chunk in foo()]
File "/home/mark/test/test.py&
Mark Shannon added the comment:
This appears to be a duplicate of https://bugs.python.org/issue44297
--
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
New changeset fb68791a26e157ed3cdeb409c8d8b6cddc7535bd by Mark Shannon in
branch 'main':
bpo-44337: Improve LOAD_ATTR specialization (GH-26759)
https://github.com/python/cpython/commit/fb68791a26e157ed3cdeb409c8d8b6cddc7535bd
Mark Shannon added the comment:
New changeset 7674c83d81905d6afe989ca3f93f08b7939b057c by Mark Shannon in
branch '3.10':
bpo-44297: Fix missing line number in generator expressions (GH-26821)
https://github.com/python/cpython/commit/7674c83d81905d6afe989ca3f93f08b7939b057c
Mark Shannon added the comment:
I think this is a combination of https://bugs.python.org/issue44297 and the
PREDICT macros.
I don't have a windows machine to confirm this on, but I suspect that if you
rewrite `doit` as:
def doit():
o = ((1,2), (3,4))
o
Change by Mark Shannon :
--
pull_requests: +25402
pull_request: https://github.com/python/cpython/pull/26821
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
New changeset 82e5c28af7049c4f5343c808f172cbe2e145f49b by Mark Shannon in
branch 'main':
bpo-44297: Fix missing line number in generator expressions (GH-26801)
https://github.com/python/cpython/commit/82e5c28af7049c4f5343c808f172cbe2e145f49b
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25382
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26801
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Thanks Anthony, that's a big help.
--
___
Python tracker
<https://bugs.python.org/issue44297>
___
___
Python-bugs-list mailin
Mark Shannon added the comment:
Ned, is this a regression (does 3.9 do the right thing on Windows) or an
inconsistency between Mac and Windows?
I suspect this might have something to do with the PREDICT macros. If that the
were the case 3.9 should show the same inconsistency between Windows
Mark Shannon added the comment:
New changeset 0982ded179f280176868c1c4eccf77bf70687816 by Mark Shannon in
branch 'main':
bpo-44032: Move pointer to code object from frame-object to frame specials
array. (GH-26771)
https://github.com/python/cpython/commit
Change by Mark Shannon :
--
pull_requests: +25357
pull_request: https://github.com/python/cpython/pull/26771
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
No problem, I've added a simple test.
--
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issue2>
___
_
Change by Mark Shannon :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue2>
___
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25355
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26768
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
When calling frame.clear(), the globals (and builtins) are cleared.
This is not the case in 3.10. We should restore the 3.10 behavior, as there is
no reason not to.
Victor, you've mentioned this problem. Did you have a specific example I can
add as a test
Change by Mark Shannon :
--
assignee: Mark.Shannon -> eric.snow
___
Python tracker
<https://bugs.python.org/issue43693>
___
___
Python-bugs-list mai
Change by Mark Shannon :
--
pull_requests: +25344
pull_request: https://github.com/python/cpython/pull/26759
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
New changeset ab030d6f9d73e7f6c2213c2e308d1ceb04761485 by Sergey Fedoseev in
branch 'main':
bpo-38211: Clean up type_init() (GH-16257)
https://github.com/python/cpython/commit/ab030d6f9d73e7f6c2213c2e308d1ceb04761485
--
nosy: +Mark.Shannon
Mark Shannon added the comment:
This is going in the wrong direction.
Rather than add more complex instructions for use only by pattern matching, we
need to simplify the individual operations and re-use existing instructions.
That way pattern matching can benefit from the general performance
Mark Shannon added the comment:
What does "seem wrong" mean?
What exactly is the problem?
--
___
Python tracker
<https://bugs.python.org/issue44417>
___
__
Change by Mark Shannon :
--
pull_requests: +25306
pull_request: https://github.com/python/cpython/pull/26718
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
New changeset eecbc7c3900a7f40d8498b151db543a202c72f74 by Mark Shannon in
branch 'main':
bpo-44338: Port LOAD_GLOBAL to PEP 659 adaptive interpreter (GH-26638)
https://github.com/python/cpython/commit/eecbc7c3900a7f40d8498b151db543a202c72f74
Change by Mark Shannon :
--
pull_requests: +25226
pull_request: https://github.com/python/cpython/pull/26639
___
Python tracker
<https://bugs.python.org/issue44
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25225
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26638
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Yes. Simpler is good.
I think it will also be better for performance:
In general, we don't know what X is in `from Y import X`. It could be a module
or anything else.
However, if we are accessing an attribute it is quite likely to be a module or
class
Mark Shannon added the comment:
It looks like I've been a bit unfair to the address sanitizer.
It does appear to produce incorrect locations sometimes, but that's not really
a false positive and the reports are generally useful.
--
___
Python
Mark Shannon added the comment:
New changeset 54cb63863f19a7c64d9a3a5fd97bdfc0dd7ab374 by Mark Shannon in
branch 'main':
bpo-44348: Move trace-info to thread-state (GH-26623)
https://github.com/python/cpython/commit/54cb63863f19a7c64d9a3a5fd97bdfc0dd7ab374
Mark Shannon added the comment:
New changeset e117c0283705943189e6b1aef668a1f68f3f00a4 by Mark Shannon in
branch 'main':
bpo-44337: Port LOAD_ATTR to PEP 659 adaptive interpreter (GH-26595)
https://github.com/python/cpython/commit/e117c0283705943189e6b1aef668a1f68f3f00a4
Mark Shannon added the comment:
No, this is done
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
This line seems to be responsible for most of the failures:
https://github.com/python/cpython/blob/main/Objects/frameobject.c#L985
Which does appear to be a true positive.
--
___
Python tracker
<ht
Mark Shannon added the comment:
What commit are you running that on?
--
___
Python tracker
<https://bugs.python.org/issue44363>
___
___
Python-bugs-list mailin
Mark Shannon added the comment:
I still get quite a few failures on the main branch.
It seems like ceval.c:1600 upsets the sanitizer, at least for gcc.
There isn't anything wrong with that line, but as I plan to change it anyway I
guess it doesn't matter:
https://github.com/python/cpython
Change by Mark Shannon :
--
pull_requests: +25209
pull_request: https://github.com/python/cpython/pull/26624
___
Python tracker
<https://bugs.python.org/issue44
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
If I run the following on main
./configure --with-address-sanitizer
make clean
make -j12 test
I get 22 failures.
So something is broken.
test_lib2to3 does fork; at least it does when I run it under gdb
Change by Mark Shannon :
--
nosy: +Mark.Shannon
nosy_count: 9.0 -> 10.0
pull_requests: +25208
pull_request: https://github.com/python/cpython/pull/26623
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
Running the buildbot for https://github.com/python/cpython/pull/26595
results in failures:
https://buildbot.python.org/all/#/builders/581/builds/63
Which claim that the address calculation in `LOAD_ATTR_MODULE` is out of bounds.
The tests pass with an added
Mark Shannon added the comment:
Pablo,
Is there a bpo issue for the buildbot failures on Windows?
The failures I've been seeing are C stack overflows.
Long term, I expect to fix it by decoupling the C and Python stacks.
In the short term I have a couple of changes that might get it working
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25178
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26595
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
Port the implementation of LOAD_GLOBAL to the new adaptive interpreter
Once this and https://bugs.python.org/issue44337 are implemented we can remove
the old opcache.
--
messages: 395272
nosy: Mark.Shannon
priority: normal
severity: normal
status
New submission from Mark Shannon :
Port the implementation of LOAD_ATTR to the new adaptive interpreter
--
messages: 395271
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Port LOAD_ATTR to adaptive interpreter
___
Python
Mark Shannon added the comment:
New changeset 001eb520b5757294dc455c900d94b7b153de6cdd by Mark Shannon in
branch 'main':
bpo-44187: Quickening infrastructure (GH-26264)
https://github.com/python/cpython/commit/001eb520b5757294dc455c900d94b7b153de6cdd
Mark Shannon added the comment:
Basic blocks have only a single exit, at the end.
https://en.wikipedia.org/wiki/Basic_block
If the devguide says otherwise it is wrong.
--
___
Python tracker
<https://bugs.python.org/issue42
Change by Mark Shannon :
--
pull_requests: +25111
pull_request: https://github.com/python/cpython/pull/26516
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
New changeset 937cebc93b4922583218e0cbf0a9a14705a595b2 by Mark Shannon in
branch 'main':
bpo-44298: Fix line numbers for early exits in with statements. (GH-26513)
https://github.com/python/cpython/commit/937cebc93b4922583218e0cbf0a9a14705a595b2
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +25109
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/26513
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Why this occurs:
with cm:
A
break
translates to something like:
ex = cm.__exit__; cm.__enter__() # with cm
A
ex(...)
goto loop_end # break
So, the break is traced after the exit call.
However, this doesn't seem consistent with try
Mark Shannon added the comment:
For context, this behavior was introduced in https://bugs.python.org/issue43933
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Mark Shannon :
--
pull_requests: +25027
pull_request: https://github.com/python/cpython/pull/26432
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
New changeset f8a95df84bcedebc0aa7132b3d1a4e8f000914bc by Mark Shannon in
branch 'main':
bpo-44206: Add a version number to dictionary keys (GH-26333)
https://github.com/python/cpython/commit/f8a95df84bcedebc0aa7132b3d1a4e8f000914bc
Mark Shannon added the comment:
New changeset 6cc800d3634fdd002b986c3ffe6a3d5540f311a0 by Eric Snow in branch
'main':
bpo-43693: Clean up the PyCodeObject fields. (GH-26364)
https://github.com/python/cpython/commit/6cc800d3634fdd002b986c3ffe6a3d5540f311a0
Mark Shannon added the comment:
It is extremely unlikely, I agree. But not impossible.
I plan to fix it for 3.11. Once I've done that we can decide if backports are
worth it.
--
___
Python tracker
<https://bugs.python.org/issue44
New submission from Mark Shannon :
Should the tp_version overflow, and wrap around to a value previously used in
the opcache for LOAD_ATTR, then LOAD_ATTR could produce the wrong value.
It will take a fair bit of contrivance and a long time to do this, but it is
possible:
Run some code ~2000
Mark Shannon added the comment:
Which optimizations?
LOAD_GLOBAL:
Using a keys version instead of a whole dict version means that LOAD_GLOBAL
won't leak references. It also means that we can (in the future) remove the PEP
509 version and save 8 bytes per dict.
LOAD_ATTR
Mark Shannon added the comment:
http://theses.gla.ac.uk/2975/1/2011shannonphd.pdf page 128.
It means we don't need to cache a pointer to the keys, just the version number.
The version number is half the size (for 64 bit machines) and using it means
that we don't leak keys
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24925
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/26333
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
The version is on the dict keys. It changes if the dict keys object changes in
a meaningful way.
So, no it doesn't change if a value is changed.
Nor would it change if the keys were shared and a new key-value pair is added
to a dict, but that key was already
Mark Shannon added the comment:
What's the test case, exactly?
ref.py for the other issue doesn't crash if I change "func.py" to "ref.py"
otherwise it just complains that "func.py" doesn't exist.
--
___
Python tra
Change by Mark Shannon :
--
pull_requests: +24891
pull_request: https://github.com/python/cpython/pull/26285
___
Python tracker
<https://bugs.python.org/issue44
New submission from Mark Shannon :
In order to specialize calls to Python functions, or to inline them, we need to
know that the code object has not changed. It is also useful to know that the
globals, builtins and various defaults haven't changed either. Rather than
attempting to check
Mark Shannon added the comment:
The memory saving comes from converting:
Py_ssize_t dk_size;
dict_lookup_func dk_lookup;
to:
uint8_t dk_log2_size;
uint8_t dk_loopup_kind; /* Only 3 possible values */
uint32_t dk_version;
which saves 8 bytes on a 64 bit machine (no saving
New submission from Mark Shannon :
Add a version number to dict keys.
PEP 509 added a version number to dicts. Unfortunately this is no use for
optimizing attribute loads and store on instances.
We need to know whether the keys are as expected, not the dict as that is
likely to be different
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24868
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26264
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
As described in PEP 659 (Specializing Adaptive Interpreter) the first part of
implementing specialization is to implement the machinery to do the quickening.
Conceptually, this is fairly simple: add a new field to the code object, which
points to the first
Mark Shannon added the comment:
I have to admit that I find the truncated version more readable.
Some sort of truncation is useful, as a regex could be thousands of character
long.
Adding the offset to the warning message seems like a useful addition.
--
nosy: +Mark.Shannon
Mark Shannon added the comment:
New changeset 0acdf255a51b836c0b44f3676797620322974af3 by Mark Shannon in
branch '3.10':
[3.10] bpo-43933: Force RETURN_VALUE bytecodes to have line numbers (GH-26061)
https://github.com/python/cpython/commit/0acdf255a51b836c0b44f3676797620322974af3
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24716
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26076
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
pull_requests: +24702
pull_request: https://github.com/python/cpython/pull/26061
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
pull_requests: +24699
pull_request: https://github.com/python/cpython/pull/26059
___
Python tracker
<https://bugs.python.org/issue40
Change by Mark Shannon :
--
pull_requests: +24694
pull_request: https://github.com/python/cpython/pull/26054
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
Duplicate of https://bugs.python.org/issue43933
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
It is very little effort to add back the old function, so that isn't the
problem. It won't work properly, but it never did anyway. So I guess that's
sort of compatible.
Maybe the best thing is to put a big red warning in the docs and hope that
warns away
Mark Shannon added the comment:
I know PyCode_NewWithPosOnlyArgs is declared as "PyAPI_FUNC" but that can't
make it part of the ABI unless it has stable behavior.
It can't have stable behavior because its inputs are complex, undefined, have
altered semantics and are interlinked
Change by Mark Shannon :
--
pull_requests: +24671
pull_request: https://github.com/python/cpython/pull/26021
___
Python tracker
<https://bugs.python.org/issue40
Mark Shannon added the comment:
But what does "use it" mean?
What does setting `tstate->use_tracing = 1` do?
There is no documented behavior, so how do we know what assumptions people are
making about what happens when they set some field to 1?
As I said, we could keep the fie
Mark Shannon added the comment:
If there is no C-API function that supports your needs, feel free to suggest
one.
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Mark Shannon :
--
Removed message: https://bugs.python.org/msg393388
___
Python tracker
<https://bugs.python.org/issue43933>
___
___
Python-bugs-list m
Mark Shannon added the comment:
If there is no C-API function that supports your needs, feel free to suggest
one.
--
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
At yappi/_yappi.c:1261 sets an undocumented field on a CPython internal data
structure.
What did you believe that was supposed to do? use_tracing is not documented
anywhere.
We could add the field back and ignore it, but I doubt that would help you much
Mark Shannon added the comment:
Ned, no line numbers should never be None.
(Except under very unusual circumstances, like the trace function raising an
error)
Taking a look at the disassembly of execsitecustomize, there is a return with
no line number, which shouldn't happen
Mark Shannon added the comment:
Thanks everyone for the triaging and fixing.
--
___
Python tracker
<https://bugs.python.org/issue40222>
___
___
Python-bug
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> needs patch
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +24606
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25939
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
Consider this function, which has a syntax error on line 4.
>>> def f():
... try:
... 1/0
... except:
... pass
... except Exception:
... pass
3.9 reports an incorrect line number of 3.
3.10b reports an
Change by Mark Shannon :
--
title: Store locals and evaluation stack should be stored in a contiguous,
per-thread stack -> Function locals and evaluation stack should be stored in a
contiguous, per-thread stack
___
Python tracker
<
New submission from Mark Shannon :
Currently, the local variables (inc. cell and free vars) for functions and the
evaluation stack are kept in per-activation chunks in the frame object. This is
not a good design for modern hardware.
The local variables and stack are amongst the hottest memory
Mark Shannon added the comment:
This seems to have been fixed sometime.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Thanks for the responses.
Probably nothing to do for now.
--
resolution: -> postponed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Definitely one for Python ideas.
Quite a good idea though.
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue42
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
New changeset 33ec88ac81f23668293d101b83367b086c795e5e by Mark Shannon in
branch 'master':
bpo-43977: Make sure that tp_flags for pattern matching are inherited
correctly. (GH-25813)
https://github.com/python/cpython/commit
Change by Mark Shannon :
--
pull_requests: +24500
pull_request: https://github.com/python/cpython/pull/25813
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
I'm claiming that this is fixed.
Feel free to reopen if the additional line in tracing causes a problem.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracke
Mark Shannon added the comment:
New changeset 5979e81a212949c62c2490167c9137d233d7de64 by Mark Shannon in
branch 'master':
bpo-43933: Set frame.f_lineno during call to __exit__ (GH-25719)
https://github.com/python/cpython/commit/5979e81a212949c62c2490167c9137d233d7de64
501 - 600 of 1194 matches
Mail list logo
