Mark Shannon added the comment:
New changeset 82f897bf8f72d09f537054d64a94e645ad23d8d6 by Mark Shannon in
branch 'master':
Correct release version to 3.9 for RERAISE and WITH_EXCEPT_START bytecodes.
(#17318)
https://github.com/python/cpython/commit/82f897bf8f72d09f537054d64a94e6
Mark Shannon added the comment:
Brett,
PEP 523 makes no mention of adding a getter or setter.
Adding them is a big change to Python semantics and shouldn't, IMO, be done
without a PEP that explicit states they are going to be added.
--
___
P
Mark Shannon added the comment:
Fabio,
Can you give me a specific example where changing the bytecode via the
`__code__` attribute of a function does not work as expected?
I am assuming that adding a breakpoint on a line is equivalent to adding
`breakpoint();` at the beginning of that line
Mark Shannon added the comment:
This seems correct, but your change assumes that there is no optimisation pass
that reorders the blocks.
While the is currently true, it might not be in future.
The code that orders blocks for output should not make assumptions about the
shape of the CFG, IMO
Mark Shannon added the comment:
Exammining the bytecode for:
def finally_return():
try:
return 14
finally:
a.append(16)
We have:
2 0 SETUP_FINALLY 16 (to 18)
3 2 POP_BLOCK
5 4 LOAD_GLOBAL 0 (a
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +17180
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17737
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
With PR 17737 the bytecode is:
2 0 SETUP_FINALLY 16 (to 18)
3 2 POP_BLOCK
5 4 LOAD_GLOBAL 0 (a)
6 LOAD_METHOD 1 (append)
8 LOAD_CONST 1 (16
New submission from Mark Shannon :
Currently the COMPARE_OP instruction performs one of four different tasks.
We should break it up into four different instructions, that each performs only
one of those tasks.
The four tasks are:
Rich comparison (>, <, ==, !=, >=, <=)
Identit
Mark Shannon added the comment:
Moving work from the interpreter to the compiler is always a good idea.
Performance: The compiler is run once per code unit, the interpreter thousands
or millions of times.
The compiler is easier to test. Just match the expected bytecode with the
actual
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +17190
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17754
___
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:
Ned, I think this is fixed. Feel free to re-open if you disagree.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Ned, can you confirm that the trace has changed from 3.8 to 3.9?
The bytecode for `doit_async` is identical for 3.8 and 3.9.
--
___
Python tracker
<https://bugs.python.org/issue39
Mark Shannon added the comment:
New changeset 4c53e63cc966f98e141a09bc435b9f9c713b152d by Mark Shannon (Pablo
Galindo) in branch 'master':
bpo-39166: Fix trace of last iteration of async for loops (#17800)
https://github.com/python/cpython/commit/4c53e63cc966f98e141a09bc435b9f
Mark Shannon added the comment:
I think this is now fixed.
Ned, feel free to reopen if it still isn't fixed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
New submission from Mark Shannon :
Currently the unpacking of starred values in arguments and the right hand side
of assignments is handled in the interpreter without any help from the compiler.
The layout of arguments and values is visible to the compiler, so the compiler
should do more of
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +17388
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17984
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset 9af0e47b1705457bb6b327c197f2ec5737a1d8f6 by Mark Shannon in
branch 'master':
bpo-39156: Break up COMPARE_OP into four logically distinct opcodes. (GH-17754)
https://github.com/python/cpython/commit/9af0e47b1705457bb6b327c197f2ec
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 13bc13960cc83dbd1cb5701d9a59ac9b9144b205 by Mark Shannon in
branch 'master':
bpo-39320: Handle unpacking of *values in compiler (GH-17984)
https://github.com/python/cpython/commit/13bc13960cc83dbd1cb5701d9a59ac
Change by Mark Shannon :
--
pull_requests: +17527
pull_request: https://github.com/python/cpython/pull/18141
___
Python tracker
<https://bugs.python.org/issue39
Mark Shannon added the comment:
New changeset 8a4cd700a7426341c2074a2b580306d2d60ec839 by Mark Shannon in
branch 'master':
bpo-39320: Handle unpacking of **values in compiler (GH-18141)
https://github.com/python/cpython/commit/8a4cd700a7426341c2074a2b580306
Change by Mark Shannon :
--
nosy: +nedbat, pablogsal, skip.montanaro -Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue39537>
___
___
Python-bug
New submission from Mark Shannon :
The current line number table format has two issues that need to be addressed.
1. There is no way to express that a bytecode does not have have a line number.
The `END_ASYNC_FOR` bytecode, bytecodes for cleaning up the variable used to
store exceptions in
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +17699
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18326
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +17706
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18334
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Serhiy,
How would you handle bytecodes that have no line number?
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue39
Mark Shannon added the comment:
Serhiy,
Although the code generator is syntax directed, not all code has an explicit
piece of syntax attached.
For example in the following code:
```
def foo():
if x:
print("yes")
else:
print("no")
```
the compiler
Mark Shannon added the comment:
I'm not suggesting immediate removal of PEP 532.
I am requesting that you don't add a new function to the C API that will
prevent implementation of many meaningful optimizations to CPython.
PEP 532 does not add any API functions.
I understand that y
New submission from Mark Shannon :
The implementation of `PyObject_Vectorcall` adds unnecessary overhead to PEP
590, which undermines its purpose.
The implementation was changed in https://github.com/python/cpython/pull/17052,
which I objected to at the time.
The change has a negative impact
Mark Shannon added the comment:
Consider the case where a thread that doesn't hold the GIL attempts to get a
reference on `None`.
The problem with having a single immortal `None`, is that it will cause data
cache thrashing as two different CPUs modify the refcount on the shared
Mark Shannon added the comment:
Instead of passing `_PyRuntimeState` around everywhere, why not just let it
disappear in time.
Currently `_PyRuntimeState` manages "global" state, mainly the GIL and some
config.
Once the GIL has been migrated to the sub-interpreters, the config p
Mark Shannon added the comment:
Even if `_PyRuntime` ends up as just a list of interpreters and doesn't
disappear completely, it won't be used anything like as much as it is now.
Many of the functions that it getting passed to will no longer need it, so why
bother pass
Mark Shannon added the comment:
Having two CPUs write to the same cache line is a well known performance
problem. There's nothing special about CPython here.
The proper name for it seems to be "cache line ping-pong", but a search for
"false sharing"
Mark Shannon added the comment:
Just to add my 2 cents.
I think this a bad idea and is likely to be unsafe.
Having interpreters interfering with each other's objects is almost certain to
lead to race conditions.
IMO, objects should *never* be shared across interpreters (once interpr
New submission from Mark Shannon :
The current implementation of dicts prevents keys from being shared when the
order of attribute differs from the first instance created.
This can potentially use a considerably larger amount of memory than expected.
Consider the class:
class C:
opt
Mark Shannon added the comment:
Indeed it shouldn't.
How is that relevant?
--
___
Python tracker
<https://bugs.python.org/issue40116>
___
___
Python-bugs-l
Mark Shannon added the comment:
Just to clarify.
class AlwaysShared:
opt = DEFAULT
def __init__(self, attr, optional=None):
self.attr = attr
if optional:
self.opt = optional
class SometimesShared:
opt = DEFAULT
def __init__(self, attr, optional=None
Mark Shannon added the comment:
You can't end up with a growing set of keys.
The problem is to do with the *order* of insertion, not the number of keys.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Mark Shannon :
C++ and Java support what is known as "zero cost" exception handling.
The "zero cost" refers to the cost when no exception is raised. There is still
a cost when exceptions are thrown.
The basic principle is that the compiler generates tab
New submission from Mark Shannon :
Debuggers are allowed to change the line number of the currently executing
frame. Regardless of whether this is sensible or not, the current
implementation rather fragile.
The code makes various assumptions about the layout of the bytecode that may
not be
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +18791
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19437
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
The problem is that generators always raise an exception, even when they
terminate normally.
They don't in 2.7 and didn't prior to
https://github.com/python/cpython/commit/1f7ce62bd61488d5d721896a36a1b43befab88b5#diff-23c87bfada1d01335a3019
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +18828
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19473
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
A big -1 to this.
You are asking the whole world to take a hit on both performance and memory
use, in order to save Instagram memory.
The PR uses the term "immortal" everywhere. There is only one reference to
copy-on-write in a comment. Yet this i
Mark Shannon added the comment:
Do you have more details on your comparison?
I'm somewhat puzzled how a version that does no more work and has no jumps is
slower.
The memory hit is not immediate, but making the object header immutable
prevents changes like
https://github.com/marksh
Mark Shannon added the comment:
Eddie,
How did you compare the branching vs. non-branching implementations? I have
read the code in the PR. What is the non-branching version that you used to
compare it against?
Why not use the sign bit as the immortal bit? It simplifies the test
Mark Shannon added the comment:
On 20/04/2020 2:33 pm, Steve Dower wrote:
>
> Steve Dower added the comment:
>
>> I would expect that the negative impact on branch predictability would
>> easily outweigh the cost of the memory write (A guaranteed L1 hit)
>
> If
Mark Shannon added the comment:
New changeset 57697245e1deafdedf68e5f21ad8890be591efc0 by Mark Shannon in
branch 'master':
bpo-40228: More robust frame.setlineno. (GH-19437)
https://github.com/python/cpython/commit/57697245e1deafdedf68e5f21ad889
Mark Shannon added the comment:
What's wrong with `PyErr_GetExcInfo()` for accessing the current exception?
Victor, would you revert https://github.com/python/cpython/pull/19978 until we
decide what to do. Thanks.
--
___
Python tracker
&
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
"maybe a few setter functions as well"
Please don't add any setter functions, that would a major change to the VM and
would need a PEP.
Also, could you remove PyFrame_GetLastInstr(PyFrameObject *frame)?
The only purpose of `f_lasti` is to get
Mark Shannon added the comment:
Why do you need to specify a `PyThreadState`?
--
___
Python tracker
<https://bugs.python.org/issue40545>
___
___
Python-bug
Mark Shannon added the comment:
Those numbers are for code without immortal objects.
They don't apply in this case, as the branch misprediction rate would rise.
--
___
Python tracker
<https://bugs.python.org/is
Mark Shannon added the comment:
Ronald's test case also causes a Fatal Error on master.
2.7.18 produces the expected "RuntimeError: maximum recursion depth exceeded"
--
assignee: -> Mark.Shannon
___
Python tracker
<ht
Mark Shannon added the comment:
Duplicate of 42500
--
nosy: +Mark.Shannon
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +22449
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23568
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
I agree with Mark about slice hashing.
This looks like a deliberate design decision.
x[:] = [] should empty a sequence, not set the key-value pair (slice(None,
None, None), []) in a mapping.
However, code-objects can still be hashable even if slices are not
Mark Shannon added the comment:
New changeset 4e7a69bdb63a104587759d7784124492dcdd496e by Mark Shannon in
branch 'master':
bpo-42500: Fix recursion in or after except (GH-23568)
https://github.com/python/cpython/commit/4e7a69bdb63a104587759d77841244
Mark Shannon added the comment:
New changeset 5977a7989d49c3e095c7659a58267d87a17b12b1 by Mark Shannon in
branch 'master':
bpo-42246: Make sure that line number is correct after a return, as required by
PEP 626 (GH-23495)
https://github.com/python/cpyt
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
pull_requests: +22504
pull_request: https://github.com/python/cpython/pull/23636
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
There are two issues here.
1. The compiler is not following PEP 626 for functions with no executable code
2. dis is not robust in the case that there are no line numbers.
I want to fix 1. first, then 2
Mark Shannon added the comment:
New changeset f24b8101a01fa98b1e3ec042ba896aeb4c24d4bc by Yurii Karabas in
branch 'master':
bpo-42562: Fix issue when dis failed to parse function that has no line numbers
(GH-23632)
https://github.com/python/cpyt
Mark Shannon added the comment:
New changeset eaccc12aa986f92ea05f3f0a63cedbff78dd67f1 by Mark Shannon in
branch 'master':
bpo-42246: Don't forget the entry block when ensuring that all exits have a
line number (GH-23636)
https://github.com/python
Mark Shannon added the comment:
Thanks Yurii
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42373>
___
Mark Shannon added the comment:
What's blocking this?
It is a real pain not to be able to install packages for 3.10.
I don't much care what the format is, but since there seems to be some
difficulty in changing it, why not leave the output as `310`?
It isn't ambiguous, as lon
Change by Mark Shannon :
--
pull_requests: +22601
pull_request: https://github.com/python/cpython/pull/23743
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
Ned,
What are the failures?
I'd like to take a look, to see if things are as expected, and if there are any
tests we can add to CPython.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Mark Shannon :
The following code, when traced, produces a spurious line event for line 5:
a, b, c = 1, 1, 1
try:
a = 3
except:
b = 5
finally:
c = 7
assert a == 3 and b == 1 and c == 7
Bug reported by Ned Batchelder
https://gist.github.com/nedbat
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +22616
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23760
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
The following code, when traced, produces a spurious line events at the end of
the inner loop.
def dloop():
for i in range(3):
for j in range(3):
a = i + j
assert a == 4
Bug reported by Ned Batchelder
https://gist.github.com
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +22617
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23761
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset f5e97b72fecff9b9ced35704ec5e6cad29e2825d by Mark Shannon in
branch 'master':
bpo-42635: Mark JUMP_ABSOLUTE at end of 'for' loop as artificial to avoid
spurious line events. (GH-23761)
https://github.com/p
Mark Shannon added the comment:
Thanks Ned, that's really helpful. I'll go through those points:
Code after break/continue is no longer compiled.
Expected
First line number of modules
Expected
Except clause when no exception
https://bugs.python.org/issue42634
Double l
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> needs patch
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
New changeset 8473cf89bdbf2cb292b39c972db540504669b9cd by Mark Shannon in
branch 'master':
bpo-42246: Remove DO_NOT_EMIT_BYTECODE macros, so that while loops and if
statements conform to PEP 626. (GH-23743)
https://github.com/python/cpyt
New submission from Mark Shannon :
This function
def f():
try:
return 2
finally:
4
would generate a try of [1, 2, 4, 2]. It should generate [1, 2, 4]
and not trace the return twice.
--
assignee: Mark.Shannon
messages: 383044
nosy: Mark.Shannon, nedbat
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +22638
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23780
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset c71581c7a4192e6ba9a79eccc583aaadab300efa by Om G in branch
'master':
bpo-42615: Delete redundant jump instructions that only bypass empty blocks
(GH-23733)
https://github.com/python/cpython/commit/c71581c7a4192e6ba9a79eccc583aa
Mark Shannon added the comment:
https://github.com/python/cpython/pull/23780 fixes the finally handling.
The if-break case was fixed by earlier changes.
--
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
New changeset 5274b682bc93a04da8a69742528ac7f64633a96e by Mark Shannon in
branch 'master':
bpo-42645: Make sure that return/break/continue are only traced once when
exiting via a finally block. (GH-23780)
https://github.com/python/cpyt
Change by Mark Shannon :
--
pull_requests: +22663
pull_request: https://github.com/python/cpython/pull/23803
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
New changeset bf353f3c2d937772a8cf30b15fd8eb7b82665ccb by Mark Shannon in
branch 'master':
bpo-42246: Make sure that `f_lasti`, and thus `f_lineno`, is set correctly
after raising or reraising an exception (GH-23803)
https://github.com/python/cpyt
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, this is change is deliberate.
PEP 626 states that *all* executed code gets traced.
Occasionally that will result in NOPs in the code, that are necessary
for correctness, but cannot be removed by the optimizer.
Is this a problem in practice?
In fact this
Change by Mark Shannon :
--
resolution: fixed ->
___
Python tracker
<https://bugs.python.org/issue42634>
___
___
Python-bugs-list mailing list
Unsubscrib
Mark Shannon added the comment:
But why remove it? It is in the source code.
Do we want tracing and profiling to depend on what transformations the
optimizer does or does not make?
What lines are to be traced here? What is the last line executed?
def no_code():
if 0:
some_code
Mark Shannon added the comment:
My guess is that we are changing the CFG after computing reachability leaving
unreachable blocks marked as reachable.
--
assignee: -> Mark.Shannon
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
pull_requests: +22740
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23877
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Our reachability analysis is correct (in this case at least).
There is no unreachable code here.
In theory we could merge the two basic blocks at the end, but searching for
identical blocks and merging them is potentially quite expensive (and fiddly).
What
Mark Shannon added the comment:
New changeset f2dbfd7e20431f0bcf2b655aa876afec7fe03c6f by Mark Shannon in
branch 'master':
bpo-42634: Mark reraise after except blocks as artificial. (GH-23877)
https://github.com/python/cpython/commit/f2dbfd7e20431f0bcf2b655aa876af
Mark Shannon added the comment:
You should never have to disable optimizations.
Let's be clear about what an optimization is.
An optimization (CS not math) is a change to the program such that it has the
same effect, according to the language spec, but improves some aspect of the
beh
Mark Shannon added the comment:
What is the problem with NOPs?
If there are performance regressions in real code, then that needs to be
addressed.
If only in a few toy examples, then that is (IMO) a price worth paying for
predictable debugging and profiling.
Raymond:
Effectively it does
New submission from Mark Shannon :
While the impact of making `if 0` and `while True` appear when tracing can be
mitigated, the impact of `continue` is more of a concern.
The following loop:
while True:
if test:
continue
rest
PEP 626 requires that the `continue` is traced
Change by Mark Shannon :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Mark Shannon :
This will require a change to the internal line number table format.
PEP 626 requires all lines are traced, which makes handling of 'continue' and
other jump-to-jumps inefficient if spread across multiple lines.
In 3.9 many jump-to-jumps were
Mark Shannon added the comment:
Ned, I agree that up until 3.9, it is wasn't that simple.
But from 3.10 onward, it should be that simple.
That's the point of PEP 626.
If a transformation changes observable behavior within the scope of language
specification, then it is not an op
701 - 800 of 1219 matches
Mail list logo
