Mark Shannon added the comment:
Indeed it shouldn't.
How is that relevant?
--
___
Python tracker
<https://bugs.python.org/issue40116>
___
___
Python-bugs-list m
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:
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 interpreters
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" might
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 passing it now
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 confi
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 `None
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:
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 you want
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:
Serhiy,
How would you handle bytecodes that have no line number?
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue39
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
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 :
--
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
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/8a4cd700a7426341c2074a2b580306d2d60ec839
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 13bc13960cc83dbd1cb5701d9a59ac9b9144b205 by Mark Shannon in
branch 'master':
bpo-39320: Handle unpacking of *values in compiler (GH-17984)
https://github.com/python/cpython/commit/13bc13960cc83dbd1cb5701d9a59ac9b9144b205
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/9af0e47b1705457bb6b327c197f2ec5737a1d8f6
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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.python.or
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/4c53e63cc966f98e141a09bc435b9f9c713b152d
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:
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
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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:
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
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:
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
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:
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:
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.
--
___
Python
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/82f897bf8f72d09f537054d64a94e645ad23d8d6
Mark Shannon added the comment:
Thanks for noticing.
https://github.com/python/cpython/pull/17318
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Mark Shannon :
--
pull_requests: +16805
pull_request: https://github.com/python/cpython/pull/17318
___
Python tracker
<https://bugs.python.org/issue33
Mark Shannon added the comment:
Fabio,
If the user changes the `__code__` attribute of a function then, AFAICT, your
debugger does the wrong thing, but bytecode modification does the right thing.
Suppose we have two functions `spam` and `eggs`.
Set a break point in `eggs`, set `spam
Mark Shannon added the comment:
It sounds to me like `PyInterpreterState.eval_frame` is being used to lazily
modify the bytecode to support breakpoints.
I can see no reason why changing the bytecode can't be done via
`function.__code__`.
Suppose the code-object with the breakpoint add
Mark Shannon added the comment:
Victor,
I don't think this is a regression.
`PyThreadState` is an internal opaque data structure, which means we are free
to change it.
That the `eval_frame` is hard to access is a feature not a bug, as it
discourages misuse and enables us to remove it easily
Mark Shannon added the comment:
Fabio,
OOI what are you trying achieve by changing the frame evaluator?
--
___
Python tracker
<https://bugs.python.org/issue38
Mark Shannon added the comment:
I'm strongly opposed to this change.
PEP 523 does not specify what the semantics of changing the interpreter frame
evaluator actually is:
Is the VM obliged to call the new interpreter?
What happens if the custom evaluator leaves the VM in a inconsistent state
Mark Shannon added the comment:
Given that
def foo(): int; str; bytes; float; int; str; bytes; float
can be trivially be rewritten as
def foo(): pass
I think that benchmark is meaningless.
I really don't think we should be making claims like "40% speedup" for such
contrive
Mark Shannon added the comment:
"What's new in Python 3.8" says that this change speeds up the LOAD_GLOBAL
opcode by 40%.
That seems meaningless as a program cannot have LOAD_GLOBAL in isolation so any
test would have other bytecodes as well.
What's the evidence for the claim
Mark Shannon added the comment:
I expect to fix this is as part of the general improvements I am making to the
bytecode, interpreter and compiler.
So it should be fixed for 3.9 but not for 3.8
--
___
Python tracker
<https://bugs.python.
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +15664
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16042
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue38135>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Shannon :
Consider a flow graph of four nodes, A, B, C, D
where the A, B, C are "next" successors of each other (in order) and C branches
to B and B branches to D. Note that there is no "next" link to the D block.
The correct order is A, B, C, D bu
Change by Mark Shannon :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue21120>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Mark Shannon :
--
stage: patch review -> resolved
___
Python tracker
<https://bugs.python.org/issue21120>
___
___
Python-bugs-list mailing list
Un
Mark Shannon added the comment:
New changeset 421a72af4deaec96a49a79951b9c2546a2faa13d by Mark Shannon (Zackery
Spytz) in branch 'master':
bpo-21120: Exclude Python-ast.h, ast.h and asdl.h from the limited API (#14634)
https://github.com/python/cpython/commit
Mark Shannon added the comment:
This seems like the correct thing to do.
Since the AST changes from version to version, I don't see how these files
could reasonably be part of the limited API.
--
nosy: +Mark.Shannon
___
Python tracker
<ht
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +14529
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14735
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +13796
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13930
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
PEP 590 allows us the short circuit the __new__, __init__ slow path for
commonly created builtin types.
As an initial step, we can speed up calls to range, list and dict by about 30%.
See https://gist.github.com/markshannon/5cef3a74369391f6ef937d52cca9bfc8
Mark Shannon added the comment:
New changeset f3d909428c7c61ea32e8fbb9c8b48344e7904a53 by Mark Shannon (Michael
Blahay) in branch '3.7':
BPO-27639: Correct return type for UserList slicing operation (#13203)
https://github.com/python/cpython/commit/f3d909428c7c61ea32e8fbb9c8b48344e7904a53
Mark Shannon added the comment:
New changeset 180dc1b0f4a57c3f66351568ae8488fa8576d7f0 by Mark Shannon (Julien
Palard) in branch 'master':
bpo-28866: No type cache for types with specialized mro, invalidation is hard.
(#13157)
https://github.com/python/cpython/commit
Mark Shannon added the comment:
Do you have a reproducible way to cause this crash?
--
___
Python tracker
<https://bugs.python.org/issue25217>
___
___
Python-bug
Mark Shannon added the comment:
New changeset b1c3167c232c36ed3543ca351ff10c613639b5f5 by Mark Shannon (Michael
Blahay) in branch 'master':
bpo-27639: Correct return type for UserList slicing operation (#13169)
https://github.com/python/cpython/commit/b1c3167c232c36ed3543ca351ff10c613639b5f5
Mark Shannon added the comment:
Any reason not to close this issue?
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue34408>
___
___
Pytho
Mark Shannon added the comment:
I can't reproduce on 2.7.15rc1 on an x64 machine.
Can you confirm that this is still an issue?
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue33
Mark Shannon added the comment:
I'm closing this as a duplicate of https://bugs.python.org/issue6028
Making a recursive call in an except block cannot be handled sensibly by the
interpreter.
On exceeding the stack depth, the interpreter will raise a RecursionError.
Catching
Mark Shannon added the comment:
This failure appears to be a symptom of recursively traversing __bases__ rather
scanning __mro__ in the implementation of type.__subclasses__
The MCACHE depends on type.__subclasses__ being correct and it is not correct
for weird.py
python -i weird.py
>&
Mark Shannon added the comment:
Serhiy, for {'a': None} the dict is created using _PyDict_NewPresized() so this
makes no difference.
--
___
Python tracker
<https://bugs.python.org/issue30
Mark Shannon added the comment:
In general, I agree with Raymond that this is likely to counter-productive.
But let's not guess, let's measure :)
I expect that there are few live empty dicts at any time for most programs. In
which case there is no point in any change that attempts to save
Mark Shannon added the comment:
When I get a chance I'll see what happens with
https://github.com/python/cpython/pull/6641
--
___
Python tracker
<https://bugs.python.org/issue34
Mark Shannon added the comment:
The new behaviour looks the more correct to me.
Arguably the sequence should not include the second "4 line", but is otherwise
correct.
--
___
Python tracker
<https://bugs.python.o
Mark Shannon added the comment:
This looks like a Greenlet bug to me.
Possibly
https://github.com/python-greenlet/greenlet/commit/780a12b51fcef9adcc4f2c9a4cc5b05c2d652ba4
is incomplete.
It is not clear to me why greenlets hold their own exception state, but I
suspect that if they didn't
Mark Shannon added the comment:
Strange.
I could only reproduce this intermittently with 3.7 build.
But with a debug build, I cannot reproduce this at all.
Rebuilding Python (optimised, but without PGO) I cannot reproduce at all now.
--
___
Python
New submission from Mark Shannon <m...@hotpy.org>:
>>> os.spawnvpe(os.P_WAIT, "python2", ["python2", "-c", "print 'Hello
>>> World!'"], {})
Hello World!
0
>>> os.spawnvpe(os.P_WAIT, "python2", ["pytho
Change by Mark Shannon <m...@hotpy.org>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Change by Mark Shannon <m...@hotpy.org>:
--
pull_requests: -6338
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33318>
___
_
Change by Mark Shannon <m...@hotpy.org>:
--
pull_requests: +6338
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33318>
___
__
Change by Mark Shannon <m...@hotpy.org>:
--
keywords: +patch
pull_requests: +6337
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Mark Shannon <m...@hotpy.org>:
--
Removed message: https://bugs.python.org/msg315906
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Mark Shannon <m...@hotpy.org>:
The six complex bytecodes currently used for implementing 'with' and 'try'
statements can be replaced with just two simpler bytecodes.
The six bytecodes are WITH_CLEANUP_START, WITH_CLEANUP_FINISH,
BEGIN_FINALLY, END_FINALLY, CALL_F
Mark Shannon <m...@hotpy.org> added the comment:
The six complex bytecodes currently used for implementing 'with' and 'try'
statements can be replaced with just two simpler bytecodes.
The six bytecodes are WITH_CLEANUP_START, WITH_CLEANUP_FINISH,
BEGIN_FINALLY, END_FINALLY, CALL_F
Mark Shannon <m...@hotpy.org> added the comment:
There seems to be an implicit assumption here that fewer bytecodes is better.
But that isn't always the case.
Do you have evidence that the sequence
0 LOAD_CONST 5 ((('a', 'b', 'c'), 3, 2, 1))
2 UNPACK_SEQUENCE
Mark Shannon <m...@hotpy.org> added the comment:
It is fiddly to get the frame-setlineno code right for duplicated catch blocks,
but it is far from impossible.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Mark Shannon <m...@hotpy.org> added the comment:
I intend to reuse RERAISE to implement the exceptional case for a finally
block. Something like:
SETUP_FINALLY final
body
finalbody
JUMP exit
final:
finalbody
RERAIS
Mark Shannon <m...@hotpy.org> added the comment:
We have two competing PRs for this issue. Again.
For comparison, using the same micro-benchmark, PR 5112 has these timings:
Master branch: Mean +- std dev: 252 ns +- 4 ns
PR 5112: Mean +- std dev: 216 ns +
Mark Shannon <m...@hotpy.org> added the comment:
Even if doesn't speed things up by a significant amount, I would suggest that a
simper interpreter with smaller, simpler bytecodes is a worthy goal in itself.
--
___
Python tracke
Change by Mark Shannon <m...@hotpy.org>:
--
keywords: +patch
pull_requests: +5893
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Mark Shannon <m...@hotpy.org>:
f-string expressions can be formatted in four ways:
with or without a conversion
and
with or without a format specifier
Rather than have one bytecode that parses the opcode argument at runtime it
would be more efficient and p
Mark Shannon <m...@hotpy.org> added the comment:
I still think that option 2 would be best, but given that it is late in the
release cycle, I will accept the status quo.
A couple of comments for the record:
Constant folding occurs after AST creation, so doesn't make the AST worse.
The
Mark Shannon <m...@hotpy.org> added the comment:
So you did.
Sorry for the duplication
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Mark Shannon <m...@hotpy.org>:
--
keywords: +patch
pull_requests: +5871
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Mark Shannon <m...@hotpy.org>:
The bytecodes WITH_CLEANUP_START and WITH_CLEANUP_FINISH are complex and
implement entirely different behavior depending on what is on the stack.
This is unnecessary as the same semantics can be implemented with much simpler
byt
Mark Shannon <m...@hotpy.org> added the comment:
Nothing left to do. This is now obsolete.
--
resolution: -> out of date
stage: patch review -> resolved
status: pending -> open
___
Python tracker <rep...@bugs.python.org>
<
Mark Shannon <m...@hotpy.org> added the comment:
Serhiy, thanks for reopening this issue.
It seems to be that there are three reasonable choices:
1. Revert to 3.6 behaviour, with the addition of `docstring` attribute.
2. Change the docstring attribute to an AST node, possibly by mod
Mark Shannon <m...@hotpy.org> added the comment:
Stating that "this is a feature not a bug" does not make it so.
This breaks existing code and reduces the capabilities of the `ast` module.
For example, how does one get the location of the docstring now?
>From a syntactic poi
Mark Shannon <m...@hotpy.org> added the comment:
That issue has to do with bytecode generation, not the AST.
The AST should be an accurate representation of the Python source code.
Making a better representation of the source would be fine, but this makes it
worse.
Doc-strin
Mark Shannon <m...@hotpy.org> added the comment:
This is an unnecessary and breaking change.
Changes like this should not be made unless necessary to fix a bug.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Mark Shannon <m...@hotpy.org>:
Python 3.7.0b1+ (heads/3.7:dfa1144, Feb 22 2018, 12:10:59)
>>> m = ast.parse("def foo():\n 'help'")
>>> m.body[0].body
[]
Correct behaviour (3.6 or earlier)
>>> m = ast.parse("def foo():\n
Mark Shannon <m...@hotpy.org> added the comment:
Rebased, pushed and CI is green.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Mark Shannon <m...@hotpy.org> added the comment:
If it can wait another hour, I will be at home and can do the rebase then.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Mark Shannon <m...@hotpy.org> added the comment:
Works as expected:
>>> class C:
... exec('x: int')
...
>>> C.__annotations__
{'x': }
>>> __annotations__
{}
--
___
Python tracker <rep...@bugs.python.org&
Mark Shannon <m...@hotpy.org> added the comment:
> 3. It doesn't add a name constant. Instead it uses a name from the names list
> (which already has to contain this name).
This PR moves the constant for the name from `co_names` to `co_consts`. There
is no duplicatio
901 - 1000 of 1194 matches
Mail list logo
