Change by Mark Shannon :
--
pull_requests: +27530
pull_request: https://github.com/python/cpython/pull/29267
___
Python tracker
<https://bugs.python.org/issue45
Mark Shannon added the comment:
Do you have results for pyperformance?
--
___
Python tracker
<https://bugs.python.org/issue45636>
___
___
Python-bugs-list mailin
Change by Mark Shannon :
--
pull_requests: +27501
pull_request: https://github.com/python/cpython/pull/29238
___
Python tracker
<https://bugs.python.org/issue45
Change by Mark Shannon :
--
pull_requests: +27498
pull_request: https://github.com/python/cpython/pull/29235
___
Python tracker
<https://bugs.python.org/issue45
Mark Shannon added the comment:
Just to be clear, it is the behavior change that should be reverted, not
necessarily the new bytecode.
In fact we should probably push on with (2) and add an exception handler
wrapping the whole generator except the GEN_START. That way a GEN_START
exception
Change by Mark Shannon :
--
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issue43683>
___
___
Python-bugs-list mai
Mark Shannon added the comment:
Damien, thanks for catching this.
The change was not intended.
There are two kind of exceptions raised by send.
1. Where a pre-condition is not met, e.g. a generator is already ruuning
(caller errors)
2. When the generator/coroutine raises an exception
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 82a662e5216a9b3969054c540a759a9493468510 by Brandt Bucher in
branch 'main':
bpo-44511: Improve the bytecode for class and mapping patterns (GH-26922)
https://github.com/python/cpython/commit/82a662e5216a9b3969054c540a759a9493468510
Change by Mark Shannon :
--
nosy: +Mark.Shannon
nosy_count: 9.0 -> 10.0
pull_requests: +27492
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29228
___
Python tracker
<https://bugs.python.org/i
Mark Shannon added the comment:
If I knew where to look, I would be looking myself :)
Is the frozen module one built into CPython or one you have generated?
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +27439
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29165
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
We have multiple freelists for performance, but they are adhoc and poorly
integrated with the underlying allocator.
Improving this should give us a decent speedup.
--
assignee: Mark.Shannon
components: Interpreter Core
messages: 404788
nosy
Mark Dickinson added the comment:
I don't think this is a bug: there's still a reference to the `A` instance in
`sys.exc_info()` (specifically, in the exception traceback) in this case, so
that instance is still alive.
If you add an `except: pass` clause to your `try / finally`, you should
Mark Shannon added the comment:
What is `source`?
--
___
Python tracker
<https://bugs.python.org/issue45563>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Dickinson :
Looking at issue #35037 (which is a compatibility issue having to do with
PYLONG_BITS_IN_DIGIT), I'm wondering whether it would make sense to drop
support for 15-bit PyLong digits altogether. This would simplify some of the
code, eliminate a configuration
Mark Dickinson added the comment:
This should probably be a separate issue, but I wonder whether the 15-bit digit
option has value any more. Should we just drop that option and always use
30-bit digits?
30-bit digits were introduced at a time when we couldn't rely on a 64-bit
integer type
Mark Dickinson added the comment:
See also discussion in #44970, which is closed as a duplicate of this issue.
--
___
Python tracker
<https://bugs.python.org/issue15
Mark Dickinson added the comment:
> Is not it a duplicate of issue15996?
Yes, I think it's close enough. Thanks.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> pow() for complex numbers is rough a
New submission from Mark Shannon :
Currently, we use the `tp_version_tag` as a proxy for the state of a class when
specializing.
When we have issued 2**32 tags, we stop issuing tags. This prevents
specializing of classes that need a new tag.
We can make a few enhancements:
1. Reserve
Mark Shannon added the comment:
New changeset 8863a0fcc5f04ab7c3428e713917831f9b1deb18 by Mark Shannon in
branch 'main':
bpo-44525: Specialize simple Python calls. (GH-29033)
https://github.com/python/cpython/commit/8863a0fcc5f04ab7c3428e713917831f9b1deb18
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +27361
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29092
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
pull_requests: +27355
pull_request: https://github.com/python/cpython/pull/29033
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
Josh, please reopen if you have more to add.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
New changeset 3163e68c342434db37c69669017f96a4bb2d5f13 by Ken Jin in branch
'main':
bpo-44525: Specialize ``CALL_FUNCTION`` for C function calls (GH-26934)
https://github.com/python/cpython/commit/3163e68c342434db37c69669017f96a4bb2d5f13
Change by Mark Shannon :
--
nosy: +kj
___
Python tracker
<https://bugs.python.org/issue45527>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Shannon :
Every time we get a cache hit in, e.g. LOAD_ATTR_CACHED, we increment the
saturating counting. Takes a dependent load and a store, as well as the shift.
For fast instructions like BINARY_ADD_FLOAT, this represents a significant
portion of work done
Mark Dickinson added the comment:
> Closing this as out of date.
SGTM. Thanks.
--
___
Python tracker
<https://bugs.python.org/issue25934>
___
___
Python-
Mark Shannon added the comment:
New changeset 70945d57e775b335eb58b734d82e68484063e835 by Mark Shannon in
branch 'main':
bpo-45256: Avoid C calls for most Python to Python calls. (GH-28937)
https://github.com/python/cpython/commit/70945d57e775b335eb58b734d82e68484063e835
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45476>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Summerfield :
I mostly use the Python 3.8 docs since that's the Python I use.
However, when I tried using the 3.9 and 3.10 docs I found that the top of each
page has a long search bar (presumably for mobile devices?) but _no_ link to
the python module index. I find
Mark Shannon added the comment:
New changeset 3b3d30e8f78271a488965c9cd11136e1aa890757 by Dennis Sweeney in
branch 'main':
bpo-45367: Specialize BINARY_MULTIPLY (GH-28727)
https://github.com/python/cpython/commit/3b3d30e8f78271a488965c9cd11136e1aa890757
Change by Mark Shannon :
--
pull_requests: +27226
pull_request: https://github.com/python/cpython/pull/28937
___
Python tracker
<https://bugs.python.org/issue45
Mark Shannon added the comment:
New changeset 3901c081143ef29624f9c1cb49cc70a70321d139 by Pablo Galindo Salgado
in branch 'main':
bpo-45256: Fix cleanup of stolen locals for Python-to-Python calls (GH-28905)
https://github.com/python/cpython/commit/3901c081143ef29624f9c1cb49cc70a70321d139
Mark Shannon added the comment:
New changeset a8b9350964f43cb648c98c179c8037fbf3ff8a7d by Mark Shannon in
branch 'main':
bpo-45340: Don't create object dictionaries unless actually needed (GH-28802)
https://github.com/python/cpython/commit/a8b9350964f43cb648c98c179c8037fbf3ff8a7d
Mark Shannon added the comment:
I disagree. All that is doing is locking in the current poor interface.
We do need to extend the C API for these uses, yes. But we need an API that
addresses Cython's needs directly and at a higher level.
For example, Cython often wants to insert a frame
Mark Shannon added the comment:
Josh,
I'm not really following the details of what you are saying.
You claim "Key-sharing dictionaries were accepted largely without question
because they didn't harm code that broke them".
Is that true? I don't remember it that way. They wer
Mark Dickinson added the comment:
+1 for the removals. (We should fix #44970 too, but as you say that's a
separate issue. And I suspect that the Py_ADJUST_ERANGE1() use for float pow
should be replaced, too.)
--
___
Python tracker
<ht
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Struct names aren't exported as symbols.
$ nm ./python | grep CFrame
So, I assume that are worried about name clashes for code that has
#include "Python.h".
Isn't the threadstate struct supposed to be opaque?
If so, then shouldn't it be moved to a
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +27169
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28871
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
https://github.com/python/cpython/pull/28488 breaks PEP 523 as it bypasses
_PyEval_EvalFrame.
The fix is simple, we need to check tstate->interp->eval_frame.
--
assignee: Mark.Shannon
components: Interpreter Core
messages: 403637
nosy: Mark.S
Change by Mark Shannon :
--
pull_requests: +27145
pull_request: https://github.com/python/cpython/pull/28829
___
Python tracker
<https://bugs.python.org/issue45
Mark Shannon added the comment:
Nothing to do with it being Windows, or computed gotos.
I forgot to bump magic number again :(
--
assignee: -> Mark.Shannon
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +27125
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28802
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Sadly the MSVC team are claiming that this isn't a bug in their compiler.
Not sure how we convince them that it is. The website rejects any attempt to
reopen the issue.
How feasible would it be to use Clang or GCC on Windows
Mark Shannon added the comment:
Yes, this is worth doing, IMO.
It adds no more code and probably reduces maintenance costs as any
improvements/bug-fixes to the rust/ruby versions can be easily ported.
Even if the benefit is small, the cost is basically zero.
--
nosy: +Mark.Shannon
Mark Dickinson added the comment:
Larry: the first line was introduced in #20189. Does it still make sense to
keep it at this point?
--
nosy: +larry
___
Python tracker
<https://bugs.python.org/issue45
New submission from Mark Dickinson :
The docstring of the "type" builtin is mildly confusing. Here's what the first
few lines of the output for `help(type)` look like for me (on Python 3.10.0rc2):
class type(object)
| type(object_or_name, bases, dict)
| type(object) -> the
Mark Shannon added the comment:
New changeset a7252f88d3fa33036bdd6036b8c97bc785ed6f17 by Mark Shannon in
branch 'main':
bpo-40116: Add insertion order bit-vector to dict values to allow dicts to
share keys more freely. (GH-28520)
https://github.com/python/cpython/commit
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +27099
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28755
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
Python has two unconditional jumps, JUMP_ABSOLUTE and JUMP_FORWARD.
The bytecode compiler should ensure that all forward jumps use JUMP_FORWARD and
all backwards jumps use JUMP_ABSOLUTE.
That way, the interpreter will know that JUMP_ABSOLUTE jumps
Mark Shannon added the comment:
If some misses are caused by mixed int/float operands, it might be worth
investigating whether these occur in loops.
Most JIT compilers perform some sort of loop peeling to counter this form of
type instability.
E.g.
x = 0
for ...
x += some_float()
`x
Mark Shannon added the comment:
New changeset bd627eb7ed08a891dd1356756feb1ce2600358e4 by Mark Shannon in
branch 'main':
bpo-43760: Check for tracing using 'bitwise or' instead of branch in dispatch.
(GH-28723)
https://github.com/python/cpython/commit
Change by Mark Shannon :
--
pull_requests: +27070
pull_request: https://github.com/python/cpython/pull/28723
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
127 and 48 aren't instructions.
>>> opcode.stack_effect(48)
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid opcode or oparg
So the output from dis seems correct.
>If not, how would it deal with
New submission from Mark Shannon :
A "Normal" Python objects is conceptually just a pair of pointers, one to the
class, and one to the dictionary.
With shared keys, the dictionary is redundant as it is no more than a pair of
pointers, one to the keys and one to the values.
Mark Dickinson added the comment:
Did you by any chance get an error message resembling the following?
> "Cannot cast ufunc 'add' output from dtype('float64') to dtype('int64') with
> casting rule 'same_kind'"
(If you can give us a complete piece of code that we c
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45332>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
Since the docstring itself will always be present (attached to the function
object), removing a docstring from a co_consts tuple will only save one pointer
(8 bytes).
Given that, it would appear that (d) uses *more* memory than (b).
For the sqlalchemy
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue36841>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
I strongly favor (b) over (d).
(d) adds more complexity to MAKE_FUNCTION.
MAKE_FUNCTION represents a measurable fraction of execution time for many
programs. The more flags and branches it has, the harder it is to optimize
Mark Dickinson added the comment:
@Boštjan Mejak: I think this question belongs on a discussion forum rather than
in the Python bug tracker - as I understand it, there's no bug reported here,
and no change to the Python core proposed.
I'll close here. You might consider taking
Change by Mark Shannon :
--
assignee: docs@python -> Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue45317>
___
___
Python-bugs-list mai
Change by Mark Shannon :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue45317>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Shannon :
Assuming that issue 45256 is implemented, we will need to document it.
I'm opening a separate issue, so this doesn't get lost in the midst of 45256.
We need to:
Document the changes to gdb. Possibly at
https://wiki.python.org/moin/DebuggingWithGdb
Mark Shannon added the comment:
Regarding these three functions:
void PyLineTable_InitAddressRange(const char *linetable, Py_ssize_t length, int
firstlineno, PyCodeAddressRange *range);
int PyLineTable_NextAddressRange(PyCodeAddressRange *range);
int PyLineTable_PreviousAddressRange
Mark Shannon added the comment:
There is a clear disadvantage in moving the docstring from the function's code
object to the enclosing code object:
Docstrings are rarely looked at (relative to other operations on functions).
Inner functions and comprehensions are created many times
Mark Shannon added the comment:
PR 28488 has no NEWS entry, or What's New entry.
However, adding multiple entries will be confusing, so that's best left until
all calls to Python functions and method don't use the C stack.
--
___
Python tracker
Mark Dickinson added the comment:
New changeset bfe26bbad787c124f0ce144cff1b513ef9d2dc9c by Terry Jan Reedy in
branch 'main':
bpo-44019: Add missing comma to operator.call doc (GH-28551)
https://github.com/python/cpython/commit/bfe26bbad787c124f0ce144cff1b513ef9d2dc9c
Mark Dickinson added the comment:
Thanks for the contribution!
--
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
New changeset 6587fc60d447603fb8c631d81d9bb379f53c39ab by Antony Lee in branch
'main':
bpo-44019: Implement operator.call(). (GH-27888)
https://github.com/python/cpython/commit/6587fc60d447603fb8c631d81d9bb379f53c39ab
Mark Shannon added the comment:
Raymond,
Only split dicts need the extra field.
Classes where many instances do not have exactly the same set of attributes may
be more common than you think.
There are many reasons why some attributes may be added conditionally.
PR 28520 actually makes
Mark Shannon added the comment:
I've trying to do this since about 2011 :)
--
___
Python tracker
<https://bugs.python.org/issue45256>
___
___
Python-bugs-list m
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +26911
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/28520
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
This can be mitigated, if not entirely fixed, by storing an ordering bit vector
in the values.
This way all instances of the class SometimesShared in the example above can
share the keys.
The keys might be ("optional", "attr")
For any
Mark Shannon added the comment:
Experiments show that using `stride` just makes the code more complex,
`dk_kind` is sufficient.
We will still need ownership flags for split dicts, though.
A single flag may suffice.
--
___
Python tracker
<ht
Mark Shannon added the comment:
The only other change of any obvious significance to _PyEval_EvalFrameDefault
since 3.10a7 are the changes to MATCH_MAPPING and MATCH_SEQUENCE and those make
_PyEval_EvalFrameDefault smaller.
We may need to look elsewhere for the remaining ~4% performance
Mark Shannon added the comment:
If we are hitting a size limit for PGO, then we need to reduce the size of
_PyEval_EvalFrameDefault, to let the compiler do its job.
Force inlining stuff is not going to help.
Reverting https://github.com/python/cpython/pull/25244 for 3.10 seems
Change by Mark Shannon :
--
pull_requests: +26873
pull_request: https://github.com/python/cpython/pull/28475
___
Python tracker
<https://bugs.python.org/issue45
Change by Mark Shannon :
--
pull_requests: +26872
pull_request: https://github.com/python/cpython/pull/28474
___
Python tracker
<https://bugs.python.org/issue43
Mark Shannon added the comment:
IMO those failures are bugs in the projects listed not in CPython.
Relying on the exact meaning, or even the existence of an undocumented field of
a C struct is not, nor ever has been, safe.
The user of the field is assuming a meaning that is not known
New submission from Mark Shannon :
As the C API has evolved it has grown features in an ad-hoc way, driven by the
needs to whoever has bothered to add the code.
Maybe we should be a bit more principled about this. Specifically we should
make sure that there is a well defined interface
Change by Mark :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45134>
___
___
Python-bugs-list mailing list
Mark Shannon added the comment:
An alternative placement for the flag bits:
Stride bits in the dictkeys.
Ownership bits in the low bits of ma_used.
This would still allow us to remove the version tag at some point.
--
___
Python tracker
<ht
New submission from Mark Shannon :
Currently, if a dictionary is split, then the dictionary owns the memory for
the values. Unless the values is the unique empty-values array.
In order to support lazily created dictionaries for objects (see
https://github.com/faster-cpython/ideas/issues/72
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 064464fc38269e70f7e3a34cb25fc9085ab85782 by Mark Shannon in
branch 'main':
bpo-45219: Factor dictkey indexing (GH-28389)
https://github.com/python/cpython/commit/064464fc38269e70f7e3a34cb25fc9085ab85782
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +26802
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28389
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
> and `log` base `math.e` is likely to be less accurate than plain natural log
Nope, that's nonsense, since the two-argument form simply divides by log(base),
and while log(math.e) is mathematically not exactly 1 (its exact value,
assuming IEEE 754 binar
Mark Dickinson added the comment:
See also #36306 and #29299. There may be nothing to be done here, but it would
be nice if math.log and cmath.log at least behaved in the same way. A default
of `None` doesn't seem like a terrible option.
(BTW, just to forestall the suggestion, a default
Mark Dickinson added the comment:
Issue #43067 is similar. I'm not sure what the best solution is in this case:
- un-argument-clinic cmath.log, and document the signature using two lines
(similar to range):
log(z)
log(z, base)
- change the behaviour of cmath.log so
New submission from Mark Shannon :
Specialization and other optimizations rely on shared dictionary key properties
(version number, no deletions, etc).
However checking those properties during specialization is tricky and rather
clunky as the dict-keys can only be tested indirectly through
Change by Mark Dickinson :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue45218>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Mark Dickinson :
inspect.signature reports that the cmath.log function has an invalid signature:
Python 3.11.0a0 (heads/fix-44954:d0ea569eb5, Aug 19 2021, 14:59:04) [Clang
12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credi
Mark Shannon added the comment:
New changeset 11cdf2a6702639571554cbf3f69f57d688564540 by Mark Shannon in
branch 'main':
bpo-45203: Cleanup stats gathering code for LOAD_METHOD (GH-28352)
https://github.com/python/cpython/commit/11cdf2a6702639571554cbf3f69f57d688564540
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +26766
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28352
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
The stats for BINARY_SUBSCR and to a lesser amount LOAD_METHOD don't tell us
much about what isn't being specialized.
We should refine the stats to give us a better idea of what to optimize for.
--
assignee: Mark.Shannon
components: Interpreter Core
Mark Shannon added the comment:
New changeset c2f1e953371c25f6c42b599ba3d8797effbb503e by Irit Katriel in
branch 'main':
bpo-45152: Add HAS_CONST macro and get_const_value() function and use… (#28262)
https://github.com/python/cpython/commit/c2f1e953371c25f6c42b599ba3d8797effbb503e
Mark Roseman added the comment:
Would like to throw an idea out for feedback regarding the API reference.
I've done some preliminary work auto-generating documentation via widget
introspection. It's missing a lot, has many bugs, but is far enough along to
give a sense of what this approach
501 - 600 of 12075 matches
Mail list logo
