Change by Mark Shannon :
--
pull_requests: +22751
pull_request: https://github.com/python/cpython/pull/23896
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
In what way is it "kludgy"?
There is a mathematical theorem that states that generated code will be
imperfect,
so we will have to live with that :)
https://en.wikipedia.org/wiki/Full_employment_theorem
3.10a produces more efficient bytecode than
Mark Shannon added the comment:
The fix, which explains the bug:
https://github.com/python/cpython/pull/23896
--
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
I think this can finally be closed.
A mere 12 years after it was opened :)
PEP 626 specifies what the correct behavior is, regardless of whether
optimizations are turned on or off, so there is no point in a no-optimize
option.
The compiler is fast enough that
Mark Shannon added the comment:
Are you interested in the "what" or the "how"?
The "what":
PEP 626 defines what CPython must do in terms of tracing lines executed.
The "how":
Obviously, we want to execute Python as efficiently as possible
Mark Shannon added the comment:
There isn't much of a plan.
https://github.com/python/cpython/pull/23896 makes the optimizer respect PEP
626 w.r.t. jumps-to-jumps.
>From the point of view of optimization, there is nothing special about
>jumps-to-jumps.
Any optimization that off
Mark Shannon added the comment:
I'll briefly answer the above questions, but we could we close this issue?
If there are specific issues regarding PEP 626, please make a new issue. Feel
free to +nosy me on those issues.
I intend to review all the recent changes to the compiler in th
Mark Shannon added the comment:
New changeset 28b75c80dcc1e17ed3ac1c69362bf8dc164b760a by Mark Shannon in
branch 'master':
bpo-42246: Don't eliminate jumps to jumps, if it will break PEP 626. (GH-23896)
https://github.com/python/cpython/commit/28b75c80dcc1e17ed3ac1c693
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +22922
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24091
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
pull_requests: +22923
pull_request: https://github.com/python/cpython/pull/24094
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
dis is able to handle code with no line numbers.
>>> def f(): pass
...
>>> co = f.__code__.replace(co_linetable=b'\xff')
>>> list(co.co_lines())
[]
>>> import dis
>>> dis.dis(co)
0 LOAD_CON
New submission from Mark Shannon :
The logic for frame.f_lineno assumes that the internal C field will be updated
when f_trace is set, but that is incorrect.
Consequently, the following code
import sys
def print_line():
print(sys._getframe(1).f_lineno)
def test():
print_line
Mark Shannon added the comment:
New changeset 127dde591686816e379d1add015304e6b9fb6954 by Mark Shannon in
branch 'master':
bpo-42810: Mark jumps at end of if and try statements as artificial. (GH-24091)
https://github.com/python/cpython/commit/127dde591686816e379d1add015304
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +22930
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24099
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42803>
___
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
I don't think we want to backport it
--
stage: patch review -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.python.
Mark Shannon added the comment:
New changeset ee9f98d9f4b881ee15868a836a2b99271df1bc0e by Mark Shannon in
branch 'master':
bpo-42823: Fix frame lineno when frame.f_trace is set (GH-24099)
https://github.com/python/cpython/commit/ee9f98d9f4b881ee15868a836a2b99
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Mark Shannon :
This is an internal inconsistency. I have not identified any surface level
bugs, but it is a trap for future compiler work.
--
assignee: Mark.Shannon
messages: 384479
nosy: Mark.Shannon, larry
priority: normal
severity: normal
status: open
title
Mark Shannon added the comment:
No this is not a duplicate.
This is about making the symbol table correct for current semantics.
#42725 is about changing the behavior
--
resolution: duplicate ->
status: closed -> open
superseder: PEP 563: Should the behavior change for yield
Mark Shannon added the comment:
I've also opened #42837 which is about fixing the symbol table, so that it is
correct w.r.t. to current behavior.
I'd like to fix it ASAP as the compiler should be able to rely on the symbol
table being correct.
Of course, once we have decide
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +22967
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24138
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
The aim is to change the behavior of the symbol table to match the compiler.
The behavior has already changed at module scope.
Python 3.9.0+
>>> x:(yield None)
File "", line 1
SyntaxError: 'yield' outside function
>>>
Mark Shannon added the comment:
OK, I won't merge anything yet.
--
___
Python tracker
<https://bugs.python.org/issue42837>
___
___
Python-bugs-list m
Mark Shannon added the comment:
It looks like you are accessing the c field "f_lineno" directly.
That was never guaranteed to work, it just happened to.
You should use PyFrame_GetLineNumber()
If "f_lineno" is up to date, then it will be almost efficient as the direc
Change by Mark Shannon :
--
pull_requests: +22978
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24150
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
What's the process for making a decision on whether to make 'yield' in an
annotation a syntax error?
As a language change it should have a PEP, IMO.
The PEP will be short, and shouldn't need a long-winded acceptance process.
I just thin
Mark Shannon added the comment:
I don't see what the problem is here.
People just don't write code like that, at least not if they do code review ;)
And even, in the *extremely* rare case that they do, the code executes
correctly and reasonably quickly. It just uses a bit of ex
Change by Mark Shannon :
--
assignee: -> Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue42899>
___
___
Python-bugs-list mailing list
Unsubscrib
Mark Shannon added the comment:
The issue here is:
Is it legal to convert
if x: pass
into
pass
?
The explicit effect of the code is unchanged, BUT the implicit effect (of
calling x.__bool__) is changed.
The examples Serhiy gives are similar. If `bool(a)` evaluates to False, then
New submission from Mark Shannon :
The following examples produce incorrect line numbers, due to cleanup code not
being marked as artificial
def f():
try:
if False:
pass
except:
X
def g(a):
with a:
if False:
pass
Mark Shannon added the comment:
The question still stands.
Is converting `if x: pass` to `pass` legal?
And, if it is not, is converting
if a and b:
body
to
if a:
if b:
body
a legal transformation?
(ignoring line numbers)
If the first transformation is not allowed but
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +23027
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24202
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
They aren't quite the same. If `a` is falsey, and bool(a) has a side-effect,
then that side-effect should occur twice in:
if a and b:
...
but only once in
if a:
if b:
...
It gets more interesting (silly), if `a.__bool__()` alternated be
Change by Mark Shannon :
--
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issue42899>
___
___
Python-bugs-list mai
Mark Shannon added the comment:
It's clearer if you rewrite
if a and b:
...
as
tmp = a and b
if tmp:
...
if a is falsey then bool(a) gets called in `tmp = a and b` and `a` is assigned
to `tmp`. Then in `if tmp`, bool(a) is called again.
I agree with you about it not bei
Mark Shannon added the comment:
> How do we know `x` is falsey without calling `bool()` on it?
We don't, but in `if x: pass`, it doesn't matter.
Discounting side-effects in __bool__, the code does nothing regardless of the
Mark Shannon added the comment:
New changeset 3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67 by Mark Shannon in
branch 'master':
bpo-42908: Mark cleanup code at end of try-except and with artificial (#24202)
https://github.com/python/cpython/commit/3bd6035b6baf1a7d51b7cc2c6bb2c8
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: +23036
pull_request: https://github.com/python/cpython/pull/24209
___
Python tracker
<https://bugs.python.org/issue42
New submission from Mark Shannon :
Currently the compiler operates in three main passes:
Code-gen
Optimize
Assemble
The problem is that these passes use the same basic-block based CFG, leading to
unnecessary coupling and inefficiencies.
A basic block CFG is awkward and error-prone for the
Mark Shannon added the comment:
Does this need backporting to 3.8, or is 3.9 sufficient?
--
___
Python tracker
<https://bugs.python.org/issue39934>
___
___
Pytho
Mark Shannon added the comment:
Steve,
Please don't change the title of the issue.
Sure, the optimizer is "inconsistent".
Optimizations are applied in some cases, and not in others.
That's just how compilers work.
The issue here is whether the optimizer is allowed
Change by Mark Shannon :
--
title: Is it legal to eliminate tests of a value, when that test has no effect
on control flow -> Is it legal to eliminate tests of a value, when that test
has no effect on control flow?
___
Python tracker
<
Mark Shannon added the comment:
Pablo, are you OK closing this without a 3.8 backport?
--
___
Python tracker
<https://bugs.python.org/issue39934>
___
___
Pytho
Mark Shannon added the comment:
Unless anyone objects, I'm going to close this issue.
--
___
Python tracker
<https://bugs.python.org/issue42693>
___
___
Mark Shannon added the comment:
In general, it is hard to define what is an optimization, and what is part of
the compiler.
The original request was to disable optimizations that changed observable
behavior w.r.t. line numbers.
All optimizations now respect line numbers, so proposed
Mark Shannon added the comment:
In master, the sequence of events is:
1 call
2 line
3 line
returning
4 line
6 line
finally
6 return
which is the same as 3.7.
I now believe this is the correct trace, as the language spec states:
When a return, break or continue statement is executed in the
Change by Mark Shannon :
--
nosy: +lukasz.langa
___
Python tracker
<https://bugs.python.org/issue39934>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
The problem with using a specific syntax example, is that the optimizer doesn't
work that way. It works on the CFG.
Any specification needs to be phrased in terms of general control flow, as
other optimizations can enable this transformation.
e.g.
if
Mark Shannon added the comment:
I missed a "no" in the above, which somewhat changed the meaning!
It should have read:
"The implementation is allowed to skip any boolean test of a value, when it has
*no* effect on the flow of the program and at least one test has already bee
Mark Shannon added the comment:
It's a bug.
--
assignee: -> Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue42925>
___
___
Python-bugs-lis
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +23047
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24222
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Reducing the size of the frame object seems like a worthwhile goal, but what's
the point in increasing the maximum block stack?
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/is
Change by Mark Shannon :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42693>
___
___
Mark Shannon added the comment:
If you make calls in an exception handler that is handling a RecursionError,
without unwinding first, then it is likely that another RecursionError may
occur.
What is strange is that the second RecursionError is raised after
`print(str(e))` has printed the
Mark Shannon added the comment:
Please leave the issue open. This is a real bug.
It may not be fixed right now, but that doesn't mean it won't ever be fixed.
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.o
Mark Shannon added the comment:
Draft PEP here
https://github.com/markshannon/peps/blob/annotation-syntax-errors/pep-.rst
Guido, would you like to be co-author as it was your idea to make these things
a syntax error?
--
___
Python tracker
Mark Shannon added the comment:
Try setting the recursion limit to 10 or so and it should terminate.
The reason ctrl-C doesn't work is that you are catching the KeyboardInterrupt.
Never use a plain `except:`, use `except Exception:`
--
nosy: +Mark.Sh
Mark Shannon added the comment:
It won't solve the problem.
Maybe make it would make it easier to avoid the segfault, but some sort of
recursion/overflow check is needed.
It might make the use of the trashcan cheaper, as it only need be used when
stack space is running low.
Ultim
Mark Shannon added the comment:
I don't think so.
Tracing is already somewhat fragile, see https://bugs.python.org/issue30744.
Making it more complex is likely to add more bugs.
PEP 558 should help, as f_locals becomes a proxy.
There are some minor issues with PEP 558 (I'm not conv
Mark Shannon added the comment:
Yes, see PEP 651
--
___
Python tracker
<https://bugs.python.org/issue42951>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Shannon :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42951>
___
___
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
I see no advantage of getting rid of the limit of 20.
No one ever gets near 20 deep in practice.
Given the limit has been there for so long, it is likely that some tooling that
expects the depth of try-statements to be limited.
Why would a code generator need
Mark Shannon added the comment:
I agree with Victor, we should not be attempting to build a sandbox.
https://www.python.org/dev/peps/pep-0578/#why-not-a-sandbox
Preventing access to global variables is next to impossible. Adding more and
more hooks to prevent access to globals, merely adds
Mark Shannon added the comment:
If the point of the proposed change is not to deny access to globals, then what
is the point of it?
You say that this change is to "close a simpler gap in the audit system".
What it is that the audit system is supposed to prevent, that is currently
New submission from Mark Shannon :
Currently, to make a call to Python (modules, classes, etc, not just functions)
from C has to use the monster that is `_PyEval_EvalCode`.
As Python has adding features over the years, _PyEval_EvalCode has grown and
grown. It is time for a refactor
Mark Shannon added the comment:
Rather than:
f = create_frame_or_gen(...);
if () return f;
retval = _PyEval_EvalFrame(tstate, f, 0);
_PyObject_GC_TRACK(f);
return retval;
I was thinking:
f = create_frame(...);
if () return make_gen(f);
retval = _PyEval_EvalFrame(tstate, f, 0
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +23121
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24298
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset dea5bf9d15999bfcc58095b157c0678d45b00bdd by Irit Katriel in
branch 'master':
bpo-33387: update documentation for exception handling opcode changes (GH-24334)
https://github.com/python/cpython/commit/dea5bf9d15999bfcc58095b157c067
Mark Shannon added the comment:
New changeset c9b8e9c421b57acdcaf24fab0c93bc29b3ef7c67 by Victor Stinner in
branch 'master':
bpo-42979: Enhance abstract.c assertions checking slot result (GH-24352)
https://github.com/python/cpython/commit/c9b8e9c421b57acdcaf24fab0c93bc
New submission from Mark Shannon :
Given the lack of explicit documentation on this subject, and differing
opinions among core developers, I though it would be good to discuss how the
existence of a struct in a header file constrains the C-API.
Original PR provoking this discussion:
https
Mark Shannon added the comment:
New changeset d6c33fbd346765c6a8654dccacb2338006bf2b47 by Mark Shannon in
branch 'master':
bpo-42990: Introduce 'frame constructor' struct to simplify API for
PyEval_CodeEval and friends (GH-24298)
https://github.com/p
Change by Mark Shannon :
--
pull_requests: +23192
pull_request: https://github.com/python/cpython/pull/24368
___
Python tracker
<https://bugs.python.org/issue42
Mark Shannon added the comment:
New changeset 0332e569c12d3dc97171546c6dc10e42c27de34b by Mark Shannon in
branch 'master':
bpo-42990: Further refactoring of PyEval_ functions. (GH-24368)
https://github.com/python/cpython/commit/0332e569c12d3dc97171546c6dc10e
Mark Shannon added the comment:
Sorry. I forgot the close the issue when it was fixed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
The differences between allowing the optimiser to remove truly redundant (in
terms of control flow) boolean tests, or not, is slight.
It only matters for __bool__() calls that have side effects. Like __hash__(),
__bool__() should not produce side effects
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Option 3 with what semantics exactly?
https://docs.python.org/3/reference/datamodel.html#object.__bool__ says that
__bool__ should return True or False.
If we don't allow the optimizer the freedom to assume that __bool__ is
self-consistent and has no
Mark Shannon added the comment:
It isn't a specific optimization at all, but the combination of several.
I will change the behavior to match what appears to be the consensus.
BUT, we need to define what the semantics should be. Otherwise implementing the
compiler is just guesswork.
A
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +23232
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24417
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
3.9 crashes.
On master, I'm not seeing a crash, just a RecursionError.
>>> import unittest
>>>
>>> def f():
... raise TypeError
...
>>> class TestAudioop(unittest.TestCase):
... def test_invalid_adpcm_s
Mark Shannon added the comment:
I think this was fixed by https://github.com/python/cpython/pull/23568
The root cause seems to be the same as #42500, so I'm going to backport
https://github.com/python/cpython/pull/23568 to 3.9
--
___
P
Change by Mark Shannon :
--
pull_requests: +23290
pull_request: https://github.com/python/cpython/pull/24501
___
Python tracker
<https://bugs.python.org/issue42
Change by Mark Shannon :
--
assignee: -> Mark.Shannon
components: +Interpreter Core -Library (Lib)
versions: -Python 3.10
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Why do you think the distinction between category 1 and 2 is not clear?
If the struct if not produced, or initialized, by an API function, then it
cannot be accessed in the first place. If you can't access the struct in the
first place, then you can
Mark Shannon added the comment:
Do you have a reproducer that does not use cloudpickle?
Pickling functions seems to work correctly.
>>> import pickle
>>> def func():
... return len([])
...
>>> func2 = pickle.loads(pickle.dumps(func))
>>>
>>&
Mark Shannon added the comment:
You need to define __builtins__ in the globals dictionary.
def func(s):
return len(s)
text = "abc"
print(func(text))
FuncType = type(func)
func_globals = {"__builtins__":__builtins__.__dict__}
code = func.__code__
func2 = FuncTyp
Mark Shannon added the comment:
I don't think PR 24559 will be sufficient to fix this.
Pickled functions need to share the builtins dict, not just have a copy of it.
Adding a "builtins" parameter to types.FunctionType() should be be enough.
So:
function(code, globals, nam
Mark Shannon added the comment:
In Python 3.9 the binding is more late-ish binding, than true late binding.
Because globals['__builtins__'] is cached for each function activation,
executing functions don't see updates.
Example:
>>> def f():
... print(len(&q
Mark Shannon added the comment:
PEP 651 would prevent any crashes, although some of the tests might still fail
with a StackOverflowException, if they weren't expecting a RecursionError.
--
___
Python tracker
<https://bugs.python.org/is
Mark Shannon added the comment:
Oleksandr,
Are you saying that the current behaviour is incorrect, in the sense that it
disagrees with the documentation?
Or are you saying that the current behaviour is undesirable?
--
___
Python tracker
<ht
Mark Shannon added the comment:
Thanks for the report.
I'm looking in to it.
--
assignee: -> Mark.Shannon
priority: normal -> release blocker
stage: -> needs patch
___
Python tracker
<https://bugs.pyth
Mark Shannon added the comment:
Why are calling a population count method "bit_count()"?
That seems likely to cause confusion with "bit_length()".
I might reasonable expect that 0b1000.bit_count() be 4, not 1. It does have 4
bits.
Whereas 0b1000.population_count() is c
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +19796
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/20553
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
keywords: -patch
___
Python tracker
<https://bugs.python.org/issue40830>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
I'm worried about the performance impact of these changes, especially as many
of the changes haven't been reviewed.
Have you done any performance analysis or tests of the cumulative effect of all
these changes?
--
nosy: +Ma
Mark Shannon added the comment:
I'd be interested to see if you can get more consistent results.
Performance of modern hardware is very sensitive to memory layout, so some sort
of address randomization might be needed to remove artifacts of layout.
It is possible that the objects on the
801 - 900 of 1219 matches
Mail list logo
