Mark Shannon added the comment:
New changeset bd04fac7eb929cd11ab6985deb61d9780447fbff by Mark Shannon in
branch 'main':
bpo-46331: Do not set line number of instruction storing doc-string. (GH-30518)
https://github.com/python/cpython/commit/bd04fac7eb929cd11ab6985deb61d9780447fbff
Change by Mark Shannon :
--
assignee: -> Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue46331>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +28720
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30518
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Shannon :
Most calls (not those with *args and/or **kwargs) are compiled to the
`CALL_NO_KW` and `CALL_KW` instructions, possibly with a `PRECALL_METHOD`
prefix.
We want to unify the `CALL_NO_KW` and `CALL_KW` instructions into a single
`CALL` instruction and add
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +28718
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30515
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Ok, I'll add a news item in that case.
--
___
Python tracker
<https://bugs.python.org/issue46314>
___
___
Python-bugs-list mailin
Mark Shannon added the comment:
New changeset ec0c392f34ee2474ceacf66881f05546b540e2d1 by Mark Shannon in
branch 'main':
bpo-46314: Remove extra RESUME when compiling a lamdba. (GH-30513)
https://github.com/python/cpython/commit/ec0c392f34ee2474ceacf66881f05546b540e2d1
Mark Shannon added the comment:
Pablo, I've marked this as a release blocker so this bug doesn't get into
3.11a4.
--
keywords: -patch
nosy: +pablogsal
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +28716
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30513
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
Thanks, Ned.
--
assignee: -> Mark.Shannon
priority: normal -> release blocker
type: -> behavior
___
Python tracker
<https://bugs.python.or
Mark Dickinson added the comment:
> So, the meaning of these names like this is, "lt followed by an optional
> bitwise_or expression"?
That's certainly how I was reading it.
--
___
Python tracker
<https://bugs.py
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +28706
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30499
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +28705
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30496
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Dickinson :
PR GH-27832 inadvertently (I believe) introduced a couple of changes to
PyLong_FromLong that didn't make a lot of sense: an (unsigned long) cast was
replaced with (twodigits), and a digit count variable (counting number of
PyLong digits in a C long) had
Mark Dickinson added the comment:
Thanks for checking, Steven. Your report also helped me to notice a minor
portability bug (at Objects/longobject.c:288, where the wrong type is used in a
cast); a fix is in GH-30496.
--
___
Python tracker
<ht
Mark Dickinson added the comment:
First step in GH-30497, which changes the default to 30-bit digits
unconditionally, instead of having the default be platform dependent.
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Mark Dickinson :
--
pull_requests: +28703
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30497
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Dickinson :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46203>
___
___
Pyth
Mark Dickinson added the comment:
@swirsz: Thanks for the report.
Most of these look like false positives: we're intentionally making use of C's
unsigned arithmetic behaviour. Note that these are technically *not* overflows.
As the C standard itself says, in C99 §6.2.5, paragraph 9
Mark Dickinson added the comment:
> In the section "Comparison operators", all mentions of "bitwise" should be
> "binary".
Should they? The corresponding line from
https://docs.python.org/3/reference/expressions.html#comparisons is
comparison
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Are you using `f_lasti == -1` as a proxy for "is this an actual call or a
resumption after a yield"?
Ultimately PEP 669 will provide all the information you could need to
differentiate different events.
In the meantime...
We now make all &qu
Mark Shannon added the comment:
New changeset e028ae99ecee671c0e8a3eabb829b5b2acfc4441 by Mark Shannon in
branch 'main':
bpo-45923: Handle call events in bytecode (GH-30364)
https://github.com/python/cpython/commit/e028ae99ecee671c0e8a3eabb829b5b2acfc4441
Change by Mark Shannon :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue46166>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Mark Shannon added the comment:
Yes.
--
priority: release blocker ->
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Mark Shannon added the comment:
New changeset 3db762db72cc0da938614b1e414abb1e12ca4094 by penguin_wwy in branch
'main':
bpo-46031: add POP_JUMP_IF_NOT_NONE and POP_JUMP_IF_NONE (GH-30019)
https://github.com/python/cpython/commit/3db762db72cc0da938614b1e414abb1e12ca4094
--
nosy
Mark Dickinson added the comment:
https://github.com/ipython/ipython/issues/12843 looks very closely related, and
may be the exact same bug.
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue46
Mark Shannon added the comment:
See https://github.com/faster-cpython/ideas/discussions/210
--
___
Python tracker
<https://bugs.python.org/issue44525>
___
___
Mark Shannon added the comment:
New changeset 332e6b972567debfa9d8f3f9a4a966c7ad15eec9 by Brandt Bucher in
branch 'main':
bpo-45256: Don't track the exact depth of each `InterpreterFrame` (GH-30372)
https://github.com/python/cpython/commit/332e6b972567debfa9d8f3f9a4a966c7ad15eec9
Mark Shannon added the comment:
Yes, most of it :)
We haven't implemented points 2 and 3, yet.
I'm in no hurry to implement 3. It would clean up `gen.throw` a lot, and break
the dependency between that code and the interpreter, but it isn't urgent.
2 is more urgent. I think we need
Change by Mark Shannon :
--
pull_requests: +28621
pull_request: https://github.com/python/cpython/pull/30415
___
Python tracker
<https://bugs.python.org/issue44
Mark Shannon added the comment:
New changeset 7537f6008704b20e2d04a7ef1c0cfa34121cc5eb by Dennis Sweeney in
branch 'main':
bpo-45609: More specialization stats for STORE_SUBSCR (GH-30193)
https://github.com/python/cpython/commit/7537f6008704b20e2d04a7ef1c0cfa34121cc5eb
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +28612
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/30333
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Dickinson :
There are a couple of minor algorithmic improvements possible for the
math.isqrt fast path (which is used for nonnegative integers smaller than
2**64). On my machine those improvements produce a little over a 10% speedup.
The current algorithm for values
Mark Shannon added the comment:
New changeset a94461d7189d7f1147ab304a332c8684263dc17e by Irit Katriel in
branch 'main':
bpo-46202: Remove opcode POP_EXCEPT_AND_RERAISE (GH-30302)
https://github.com/python/cpython/commit/a94461d7189d7f1147ab304a332c8684263dc17e
--
nosy
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +28578
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30364
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Dickinson :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue46020>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
When you do:
FINUB = np.empty(len(close))
FINLB = np.empty(len(close))
you're creating two *uninitialised* arrays of values. (See the NumPy
documentation at
https://numpy.org/doc/stable/reference/generated/numpy.empty.html.)
When you then do
Mark Dickinson added the comment:
New changeset 0b58bac3e7877d722bdbd3c38913dba2cb212f13 by Mark Dickinson in
branch 'main':
bpo-37295: More direct computation of power-of-two factor in math.comb
(GH-30313)
https://github.com/python/cpython/commit/0b58bac3e7877d722bdbd3c38913dba2cb212f13
Mark Dickinson added the comment:
> Mark didn't mention his use case for rounded isqrt
Mainly for emulation of floating-point sqrt. But the number of times I've
needed rounded integer square root is small compared with the number of times
I've needed rounded integer divis
Mark Dickinson added the comment:
A new function isqrt_rem seems like a reasonably natural addition. (Though I'd
call it "isqrtrem", partly by analogy with "divmod", and partly because the
math module isn't very good
Mark Dickinson added the comment:
> I'd be happy to change the implementation to use the trailing zero counts as
> suggested.
Done in GH-30313 (though this will conflict with Serhiy's PR).
--
___
Python tracker
<https://bugs.p
Change by Mark Dickinson :
--
pull_requests: +28529
pull_request: https://github.com/python/cpython/pull/30313
___
Python tracker
<https://bugs.python.org/issue37
Mark Dickinson added the comment:
> I've created PR GH-30306 to find out.
Results: we have two Gentoo/x86 buildbots, and a 32-bit Windows build in GitHub
Actions: those machines use 15-bit digits, as a result of the logic in pyport.h
that chooses 15-bit digits if SIZEOF_VOID_P
Mark Dickinson added the comment:
Terry:
> create a fake test file test/test_xintperf [...]
Sounds reasonable, though I'm not sure I know what exact timings I'd want to
try. Maybe some of the stock integer-heavy Python benchmarks (pidigits, etc.).
I realised that I have no idea whether
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +28519
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30306
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Dickinson :
Added file: https://bugs.python.org/file50531/driver.py
___
Python tracker
<https://bugs.python.org/issue37295>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Thanks Tim for spotting the stupid mistake. The reworked timings are a bit more
... plausible.
tl;dr: On my machine, Raymond's suggestion gives a 2.2% speedup in the case
where POPCNT is not available, and a 0.45% slowdown in the case that it _is_
Mark Dickinson added the comment:
> I'm assuming you meant to write comb(67, k) instead
Aargh! That is of course what I meant, but not in fact what I timed. :-(
I'll redo the timings. Please disregard the previous message.
--
___
Python trac
Mark Dickinson added the comment:
I posted a request for information on usage of 15-bit digits to python-dev:
https://mail.python.org/archives/list/python-...@python.org/thread/ZICIMX5VFCX4IOFH5NUPVHCUJCQ4Q7QM/
--
___
Python tracker
<ht
Mark Dickinson added the comment:
> I'd be happy to see recipes added to the docs for rounded and ceiling flavors
> of isqrt, but am dubious about the value of building them in.
I'd similarly prefer to see recipes in the docs. We already have such a recipe
for c
Mark Dickinson added the comment:
> did you invent this?
The idea is no more than: "compute an extra bit, then use that extra bit to
determine which way to round". More generally, for any real number x, the
nearest integer to x (rounding ties towards +infinity) is `⌊(⌊2x⌋ + 1
Mark Dickinson added the comment:
> So which of xor-popcount and add-up-up-trailing-zero-counts is faster may
> well depend on platform.
I ran some timings for comb(k, 67) on my macOS / Intel MacBook Pro, using
timeit to time calls to a function that looked like this:
def
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +28513
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30301
___
Python tracker
<https://bugs.python.org/issu
New submission from Mark Dickinson :
Recently there was an upstream issue with GitHub Actions that caused the
Windows build steps in build.yml to hang. No output for the step was displayed
in the build logs until the entire job was eventually cancelled, after the
default step timeout of 6
Mark Dickinson added the comment:
New changeset 02b5417f1107415abaf81acab7522f9aa84269ea by Mark Dickinson in
branch 'main':
bpo-37295: Speed up math.comb(n, k) for 0 <= k <= n <= 67 (GH-30275)
https://github.com/python/cpython/commit/02b5417f1107415abaf81acab7522f9
Change by Mark Dickinson :
--
pull_requests: +28493
pull_request: https://github.com/python/cpython/pull/30277
___
Python tracker
<https://bugs.python.org/issue46
Mark Dickinson added the comment:
FWIW, when this need has turned up for me (which it has, a couple of times),
I've used this:
def risqrt(n):
return (isqrt(n<<2) + 1) >> 1
But I'll admit that that's a bit non-obvious.
--
___
Py
Mark Dickinson added the comment:
Two separate significant improvements have been pushed: thanks, Xinhang Xu!
The original PR also contained a reworking of the general case for
right-shifting a negative integer. The current code (in main) for that case
does involve some extra allocations
Mark Dickinson added the comment:
New changeset 3581c7abbe15bad6ae08fc38887e5948f8f39e08 by Xinhang Xu in branch
'main':
bpo-46055: Speed up binary shifting operators (GH-30044)
https://github.com/python/cpython/commit/3581c7abbe15bad6ae08fc38887e5948f8f39e08
Mark Dickinson added the comment:
New changeset 360fedc2d2ce6ccb0dab554ef45fe83f7aea1862 by Mark Dickinson in
branch 'main':
bpo-46055: Streamline inner loop for right shifts (#30243)
https://github.com/python/cpython/commit/360fedc2d2ce6ccb0dab554ef45fe83f7aea1862
Change by Mark Dickinson :
--
pull_requests: +28490
pull_request: https://github.com/python/cpython/pull/30275
___
Python tracker
<https://bugs.python.org/issue37
Mark Dickinson added the comment:
Changing to a documentation issue.
--
assignee: -> docs@python
components: +Documentation -Interpreter Core
nosy: +docs@python
resolution: not a bug ->
title: float(x) with large x not raise OverflowError -> Clarify conditions
under whic
Change by Mark Dickinson :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue46173>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
If we wanted to make a change, I think the part of the docs that I'd target
would be this sentence:
> a floating point number with the same value (within Python’s floating point
> precision) is returned
It's that "same value (within Python's flo
Mark Dickinson added the comment:
Yes, exactly: Python's intentionally following the normal IEEE 754 rules for
rounding a value to the binary64 format using the round-ties-to-even rounding
rule, as formalised in section 7.4 of IEEE 754-2019 (and quoted by @cykerway).
These are the exact
Mark Dickinson added the comment:
Raymond: how do you want to proceed on this? Should I code up my suggestion in
a PR, or are you already working on it?
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Mark Dickinson :
--
keywords: +patch
pull_requests: +28464
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30243
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue46055>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Dickinson :
--
nosy: -mark.dickinson
___
Python tracker
<https://bugs.python.org/issue20369>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> This should probably be a separate issue,
Specifically, issue 45569.
--
___
Python tracker
<https://bugs.python.org/issu
Mark Dickinson added the comment:
[Tim]
> The justification for the shift count isn't self-evident, and
> appears to me to be an instance of the generalization of Kummer's
> theorem to multinomial coefficients.
Not sure there's any generalisation here: I think it *is* just Kummer's
Change by Mark Dickinson :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue23522>
___
___
Pyth
Mark Dickinson added the comment:
That computation of the shift can be simplified to require only one popcount
operation. With F and Finv as before:
def comb_small(n, k):
assert 0 <= k <= n <= Nmax
return (F[n] * Finv[k] * Finv[n-k] % 2**64) << (k ^ n ^ (
Mark Dickinson added the comment:
Yes, confirmed that this is not a bug, but just one of the many consequences of
approximating real numbers by floating-point numbers.
You may be interested in math.log2 and/or int.bit_length. math.log2(x) *may*
give you more accurate results than math.log
Mark Dickinson added the comment:
One approach that avoids the use of floating-point arithmetic is to precompute
the odd part of the factorial of n modulo 2**64, for all small n. If we also
precompute the inverses, then three lookups and two 64x64->64 unsigned integer
multiplications g
Mark Dickinson added the comment:
> we can get faster code by using a small (3Kb) table of factorial logarithms
The problem here is that C gives no guarantees about accuracy of either log2 or
exp2, so we'd be playing a guessing game about how far we can go before the
calculation beco
Mark Dickinson added the comment:
Thanks, John. I should have time to review within the next week or so.
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Mark Dickinson :
--
assignee: -> mark.dickinson
___
Python tracker
<https://bugs.python.org/issue45995>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Steven: I've made a PR at https://github.com/python/cpython/pull/30174. Does
this match what you had in mind?
--
___
Python tracker
<https://bugs.python.org/issue23
Change by Mark Dickinson :
--
pull_requests: +28390
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30174
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset efd6236d36b292c2c43540132c87cf8425e8d627 by Mark Shannon in
branch 'main':
bpo-46072: Add top level stats struct (GH-30169)
https://github.com/python/cpython/commit/efd6236d36b292c2c43540132c87cf8425e8d627
Mark Shannon added the comment:
New changeset 396b58345f81d4c8c5a52546d2288e666a1b9b8b by Irit Katriel in
branch 'main':
bpo-45711: Remove type and traceback from exc_info (GH-30122)
https://github.com/python/cpython/commit/396b58345f81d4c8c5a52546d2288e666a1b9b8b
Change by Mark Shannon :
--
pull_requests: +28386
pull_request: https://github.com/python/cpython/pull/30169
___
Python tracker
<https://bugs.python.org/issue46
Mark Dickinson added the comment:
> "The mean is strongly affected by outliers and is not necessarily a typical
> example of the data points. For a more robust, although less efficient,
> measure of central tendency, see median()"
That wording sounds fine to me. I
Change by Mark Shannon :
--
pull_requests: +28363
pull_request: https://github.com/python/cpython/pull/30145
___
Python tracker
<https://bugs.python.org/issue46
Mark Shannon added the comment:
The --enable-stats option is for CPython development and shouldn't be turned on
for a release version, so I'm not really concerned about people attacking their
own machines.
--
___
Python tracker
<ht
Change by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<https://bugs.python.org/issue23522>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
New changeset 4506bbede1644e985991884964b43afa7ee6f609 by Mark Shannon in
branch 'main':
bpo-46072: Document --enable-stats option. (GH-30139)
https://github.com/python/cpython/commit/4506bbede1644e985991884964b43afa7ee6f609
Change by Mark Shannon :
--
pull_requests: +28357
pull_request: https://github.com/python/cpython/pull/30139
___
Python tracker
<https://bugs.python.org/issue46
Mark Shannon added the comment:
New changeset 62a8a0c5223f750e22ee381d3cfbdb718cf1cc93 by Brandt Bucher in
branch 'main':
bpo-45829: Check `__getitem__`'s version for overflow before specializing
(GH-30129)
https://github.com/python/cpython/commit/62a8a0c5223f750e22ee381d3cfbdb718cf1cc93
New submission from Mark Shannon :
Because functions are mutable, specifically because the __code__ attribute is
mutable, we need to version functions when specializing.
However, some specializations (for special methods mainly) only have space for
16 bit versions.
It is likely
Mark Shannon added the comment:
The problem here is that different sub-interpreters have different strings for
the same Python string.
Unless sub-interpreters are fully independent, and they cannot be due to
limitations imposed by the stable API, then all sub-interpreters must share
Mark Shannon added the comment:
New changeset 342b93f9f28746abb7b221a61d5a9b26ccbb395a by Mark Shannon in
branch 'main':
bpo-46072: Add --with-pystats configure option to simplify gathering of VM
stats (GH-30116)
https://github.com/python/cpython/commit
Mark Shannon added the comment:
New changeset 3a60bfef49b3324660a615a8e6d10710e5f669d9 by Mark Shannon in
branch 'main':
bpo-44525: Specialize for calls to type and other builtin classes with 1
argument. (GH-29942)
https://github.com/python/cpython/commit
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +28338
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30116
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
New changeset 0b50a4f0cdee41a18fb4ba6e75569f9cfaceb39e by Mark Shannon in
branch 'main':
bpo-46039: Split yield from in two (GH-30035)
https://github.com/python/cpython/commit/0b50a4f0cdee41a18fb4ba6e75569f9cfaceb39e
Mark Shannon added the comment:
PR 29581 resulted in a 1% slowdown, which is not terrible, but code not using
except* should not be slowed down at all.
IMO, the way to avoid the slowdown is to implement except* using the existing
instruction set (perhaps with a few minor additions)
We
301 - 400 of 17965 matches
Mail list logo
