Tim Peters added the comment:
Oh yes - please do. It's not just pickle size - going through str() makes
(un)pickling quadratic time in both directions if components are large. Pickle
the component ints instead, and the more recent pickle protocol(s) can do both
directions in linear
Tim Peters added the comment:
Dennis, combinations("aaabbbcccddd") isn't a valid call - the function requires
a "how many?" argument too. If, e.g., we were asking for groups of 4, then
combinations("aaabbbcccddd", 4) generates the 4-tuple ('a',
Change by Tim Peters :
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue44197>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
+1. Although, to be fair, I'd personally be happy if (+-0)**inf returned, say,
1.375 instead ;-)
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
Under the released 3.9.5 for 64-bit Win10, raising to the power 2 is clearly
much slower than multiplying directly:
C:\Windows\System32>py -3 -m timeit -s "x=151" "x*x"
1000 loops, best of 5: 30 nsec per loop
C:\Windows\System32>
Change by Tim Peters :
--
keywords: +patch
pull_requests: +25248
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26662
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
This is a stab at reducing overhead for small exponents, along the lines I
sketched:
https://github.com/python/cpython/pull/26662
Unfortunately, I've been unable to convince BPO and GitHub to recognize that
the PR is related to this report. Did something
Tim Peters added the comment:
New changeset 9d8dd8f08aae4ad6e73a9322a4e9dee965afebbc by Tim Peters in branch
'main':
bpo-44376 - reduce pow() overhead for small exponents (GH-26662)
https://github.com/python/cpython/commit/9d8dd8f08aae4ad6e73a9322a4e9de
Tim Peters added the comment:
Closing this now because the pull request did, I believe, all that can be done
at the function level. Exponents of 1 and 2 are well within a factor of 2 of
repeated multiplication now, and it's essentially a tie at exponent 3 now.
Above that, pow() wins no
Tim Peters added the comment:
I agree Raymond's `before_and_after()` looks like an elegant, efficient, and
usable approach to this.
One minor nit: there's no need for the `iter()` call in:
yield from iter(transition)
Indeed, it confused me at first, because `yield from x
Tim Peters added the comment:
If you don't use the 'after` iterator, then of course you'll never see the
values (if any) it would have yielded.
How could it possibly be otherwise? By design and construction, the `before`
iterator ends before yielding the first (if any) trans
Tim Peters added the comment:
That said, if you really do want those semantics, it's easy to build on top of
Raymond's API:
def takewhile_plus_one_more_if_any(pred, iterable):
from itertools import islice, chain
before, after = before_and_after(pred, iterable)
return ch
Tim Peters added the comment:
Dan, the Microsoft URL in your message gives a 404 for me. Did you perhaps mean
to end it with "cng-portal" (instead of "cng-por")?
--
nosy: +tim.peters
___
Python tracker
<https://bug
Tim Peters added the comment:
> It looks like the difference one would expect from (fast) human input)
Nope, the timestamps in the original report are about 3 hours apart (10808+
seconds).
Reports like these are often much clearer if they state the timezone of the
system they're ru
Tim Peters added the comment:
If you want to pursue changing what utcnow() does, python-ideas or python-dev
would probably need to be involved. Backward-incompatible changes are very hard
sells.
As Paul Ganssle noted here,
https://blog.ganssle.io/articles/2019/11/utcnow.html
in Python 2
Tim Peters added the comment:
The binary power operator (`**`) has higher precedence than the unary negation
operator (`-`).
That is, -x**y groups as -(x**y).
Not a bug - that's how it was designed and how it's documented.
Note that this isn't novel, either. For example, t
Tim Peters added the comment:
Sorry, I'm just going to close this. For values of all numeric types now,
`bool(x)` returns the same as `x != type(x)(0)`. Besides being
backward-incompatible, making an exception for NaN would be jarringly
inconsistent.
Note that you don't nee
Tim Peters added the comment:
The CPython Windows installer has a "thank you" box at the end:
"""
Special Windows thanks to Mark Hammond, without whose years of freely shared
Windows expertise, Python for Windows would still be Python for DOS.
""&qu
Tim Peters added the comment:
The merge order was mentioned on python-dev today, and a quick web searched
turned up a revision of Vincent Jugé's "Adaptive Shivers Sort: An Alternative
Sorting Algorithm" paper I hadn't seen before:
https://arxiv.org/pdf/1809.08411.pdf
Tim Peters added the comment:
Added new runstack.py.
New `shivers2()` adds the implementation of adaptive ShiversSort from Vincent's
later paper. While the code is simpler, it appears to behave identically.
New `shivers3()` adds, from the same paper, the new "length-adaptive
S
Tim Peters added the comment:
And another runstack.py adds `shivers4()`, which reworks `shivers3()`
(length-adaptive ShiversSort) so that division, log2(), and floor() aren't used
anymore. It does need a loop, though, which needs to go around a number of
times `k` such that k i
Change by Tim Peters :
--
Removed message: https://bugs.python.org/msg400568
___
Python tracker
<https://bugs.python.org/issue45045>
___
___
Python-bugs-list m
Change by Tim Peters :
Removed file: https://bugs.python.org/file50242/runstack.py
___
Python tracker
<https://bugs.python.org/issue45045>
___
___
Python-bugs-list mailin
Tim Peters added the comment:
And another runstack.py adds `shivers4()`, which reworks `shivers3()`
(length-adaptive ShiversSort) so that division, log2(), and floor() aren't used
anymore. It does need a loop, though, which needs to go around a number of
times `k` such that k i
Tim Peters added the comment:
New runstack.py mostly adds comments about a surprise: the idea that
length-adaptive ShiversSort eeks out better results than powersort appears
nearly unique to the specific "0.80" cutoff used in the random-case generation
code to pick between t
Change by Tim Peters :
--
keywords: +patch
pull_requests: +26550
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/28108
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
I created a PR that implements the powersort merge strategy:
https://github.com/python/cpython/pull/28108
Across all the time this issue report has been open, that strategy continues to
be the top contender. Enough already ;-) It's indeed a more diff
Tim Peters added the comment:
New changeset 5cb4c672d855033592f0e05162f887def236c00a by Tim Peters in branch
'main':
bpo-34561: Switch to Munro & Wild "powersort" merge strategy. (#28108)
https://github.com/python/cpython/commit/5cb4c672d8550335
Change by Tim Peters :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Peters added the comment:
Unfortunately, you're getting hurt by the "autojunk" feature (see the docs). If
you turn it off, you'll get a result much more to your liking:
>>> print(SequenceMatcher(None, a, b).ratio())
0.3431803896920176
>>> print(Sequ
Tim Peters added the comment:
I have no idea why you think the result should be 0.2. 0.5630188679245283 looks
correct to me with autojunk disabled:
sm = SequenceMatcher(None, a, b, autojunk=False)
total = 0
for m in sm.get_matching_blocks():
print(m, repr(a[m.a : m.a + m.size
Tim Peters added the comment:
Please stop re-opening this. The issue tracker is not a "help desk", and your
confusions aren't necessarily Python bugs ;-) If you post something that looks
like an actual bug, I'll re-open the report.
SequenceMatcher works on sequences
New submission from Tim Holy :
This is a lightly-edited reposting of
https://stackoverflow.com/questions/69164027/unreliable-results-from-timeit-cache-issue
I am interested in timing certain operations in numpy and skimage, but I'm
occasionally seeing surprising transitions (not ent
Tim Holy added the comment:
To make sure it's clear, it's not 0.08ns/function call, it's a loop and it
comes out to 0.08ns/element. The purpose of quoting that number was to compare
to the CPU clock interval, which on my machine is ~0.4ns. Any operation that's
less t
Tim Holy added the comment:
> And I hope that Tim Holy is interested too :-)
Sure, I'll bite :-). On the topic of which statistic to show, I am a real fan
of the histogram. As has been pointed out, timing in the real world can be
pretty complicated, and I don't think it does a
Change by Tim Holy :
--
resolution: not a bug ->
___
Python tracker
<https://bugs.python.org/issue45261>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
CPython's log() builds on the platform C's libm facilities, and C simply
doesn't define primitives capable of producing a worst-case < 1 ulp error
2-argument log in reasonable time. Instead we have to build it out of two
separate log operatio
New submission from Tim Peters :
The code could typically be faster if it did what its comments imply it does:
skip the expense of PyObject_RichCompareBool() entirely for the first pair of
tuple elements. It actually always calls PyObject_RichCompareBool() on the
first pair, and only if that
Tim Peters added the comment:
FYI, this is fallout from a StackOverflow mystery:
https://stackoverflow.com/questions/69468552/efficiency-of-sorting-by-multiple-keys-in-python/69610671#
--
___
Python tracker
<https://bugs.python.org/issue45
Tim Peters added the comment:
The attached tupsort.py gives a simple. focused example. Typical output on my
box:
float 3.10
(float,) 11.75
[float]25.68
It's sorting a large list of floats. In the first line the list contains plain
floats. In the second line, each floa
Change by Tim Peters :
--
keywords: +patch
pull_requests: +27345
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29076
___
Python tracker
<https://bugs.python.org/issu
Change by Tim Peters :
--
assignee: -> tim.peters
___
Python tracker
<https://bugs.python.org/issue45530>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
Stefan, I have scant memory of ever caring, but, if I did, I got over it ;-)
>>> math.nan == math.nan
False
>>> {math.nan : 5}[math.nan]
5
That is, PyObject_RichCompareBool() takes object identity as overriding __eq__;
that's why the
Tim Peters added the comment:
Stefan, I looked at that old PR and can't find anywhere I suggested that he
change the unsafe_tuple_compare() logic. I just _asked_ him "I'm curious about
what the patched Python prints for this program:".
And, in fact, that program sho
Tim Peters added the comment:
> Elliot shortly after retrated from the approach, saying he
> rewrote unsafe_tuple_compare to move the less-than after
> the equality testing, to make sure it's 100% consistent".
I remember at the time having no idea what he meant by that com
Tim Peters added the comment:
It's rare that an optimization is a _pure_ win. Some cases win, others lose.
There's almost never "a proof" of net gain ending with "QED".
Of course it's dead easy to construct examples where "many duplicates in the
first
Tim Peters added the comment:
I think Dennis's example is fatal: from section 6.10 ("Comparisons"):
"""
Comparisons can be chained arbitrarily, e.g., `x < y <= z` is equivalent to `x
< y and y <= z`, except that y is evaluated only once (but in bo
Tim Peters added the comment:
> I see you mentioned that PyObject_RichCompareBool(..., Py_EQ) might be
> faster for example because it checks identity.
For example, in tupsort.py replace
xs = [random() for _ in range(length)]
with
xs = ['z' * 100 for _ in rang
Tim Golden added the comment:
Closing as no longer reproducible in the current codebase on my current laptop
--
resolution: -> not a bug
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tim Peters added the comment:
+1 "in theory". But I too don't know whether any platforms would be adversely
affected, or how to find out :-(
--
nosy: +tim.peters
___
Python tracker
<https://bugs.pyt
Tim Golden added the comment:
Closing this as out-of-date. The original bug was reported against 2.7 and
Win8, both of which are either end-of-life now.
No follow up in 9 years and I'm quite certain that modern Pythons handle all
manner of Unicode chars on the co
Tim Peters added the comment:
Stefan, thanks - I think I understand what you're driving at now.
You're (re)discovering that sorting by lexicographic ordering rules is
_inherently_ suboptimal if list elements can only be compared "starting at
index 0" each time. Not j
Tim Golden added the comment:
https://bugs.python.org/issue40915 is related
Retargetting for 3.10+
--
assignee: -> tim.golden
versions: +Python 3.10, Python 3.11 -Python 2.7, Python 3.2
___
Python tracker
<https://bugs.python.org/iss
Tim Golden added the comment:
(switching stage to resolved because it's closed/rejected; sorry for the noise)
--
stage: -> resolved
___
Python tracker
<https://bugs.python.org
Change by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<https://bugs.python.org/issue40915>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Tim Golden :
--
resolution: -> later
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue2733>
___
Tim Golden added the comment:
Superseded by issue40915
--
___
Python tracker
<https://bugs.python.org/issue2733>
___
___
Python-bugs-list mailing list
Unsub
Change by Tim Golden :
--
resolution: later -> duplicate
superseder: -> multiple problems with mmap.resize() in Windows
___
Python tracker
<https://bugs.python.org/
Tim Peters added the comment:
To be concrete, here's an implementation of a full-blown, stable lexicographic
sort based on "bucket refinement". `xs` is a list of sequences to be sorted in
lexicographic order. The types of the sequences don't matter (lists, tuples,
s
Tim Peters added the comment:
New changeset 51ed2c56a1852cd6b09c85ba81312dc9782772ce by Tim Peters in branch
'main':
bpo-45530: speed listobject.c's unsafe_tuple_compare() (GH-29076)
https://github.com/python/cpython/commit/51ed2c56a1852cd6b09c85ba8
Change by Tim Peters :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Tim Golden :
--
keywords: +patch
pull_requests: +27477
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29213
___
Python tracker
<https://bugs.python.org/issu
Tim Golden added the comment:
New changeset aea5ecc458084e01534ea6a11f4181f369869082 by Tim Golden in branch
'main':
bpo-40915: Fix mmap resize bugs on Windows (GH-29213)
https://github.com/python/cpython/commit/aea5ecc458084e01534ea6a11f4181
Change by Tim Golden :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Tim Golden :
Following issue40915 a few small items still need to be addressed, mostly
cosmetic / naming:
* A comment should have been removed but wasn't
* A comment should have been added but wasn't
* The use of the string "TEST" should be avoided i
Change by Tim Golden :
--
keywords: +patch
pull_requests: +27511
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29247
___
Python tracker
<https://bugs.python.org/issu
Tim Golden added the comment:
New changeset 7bddd96982072d04bd6314da1ee7f40b7f875f00 by Tim Golden in branch
'main':
bpo-45621: Small changes to mmap (GH-29247)
https://github.com/python/cpython/commit/7bddd96982072d04bd6314da1ee7f4
Change by Tim Golden :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Tim Peters :
A number of contexts allow specifying a tuple of arguments to be passed later
to a function. The Thread constructor is a fine example, and happened to come
up (again! for me) here today:
https://stackoverflow.com/questions/69858950/why-do-we-have-to-add-comma
Change by Tim Peters :
--
title: Promise that the long-time truth that `args=list` works -> Promise the
long-time truth that `args=list` works
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
Serhiy, we haven't documented such stuff, and, indeed, I've been burned by it
but much more often in the case of multiprocessing.Process. But note that I'm
SWAPPING the order of your last two lines. In the original, you mutated the
argument _b
Tim Peters added the comment:
Changed stage back to "needs patch", since Raymond appears to have closed his
PR. Raymond, what's up with that?
--
stage: patch review -> needs patch
___
Python tracker
<https://bugs.
Tim Peters added the comment:
Note that, on Windows, ldexp() in the presence of denorms can truncate.
Division rounds, so
assert x / 2**i == ldexp(x, -i)
can fail.
>>> import math
>>> d = math.nextafter(0.0, 1.0)
>>> d
5e-324
>>> d3 = 7 * d # .
Tim Peters added the comment:
Mark, ya, MS's Visual Studio's ldexp() has, far as I know, always worked this
way. The code I showed was run under the 2019 edition, which we use to build
the Windows CPython.
Raymond,
x = float(i)
is screamingly obvious at first glance.
Tim Peters added the comment:
> Objects/longobject.c::long_true_divide() uses ldexp() internally.
> Will it suffer the same issues with subnormals on Windows?
Doesn't look like it will. In context, looks like it's ensuring that ldexp can
only lose trailing 0 bits, so that
Tim Peters added the comment:
But I would like to leave it alone. Extended precision simply is not an issue
on any current platform I'm aware of ("not even Windows"), and I would, e.g.,
hate trying to explain to users why
1 / 2731 != 1.0 / 2731.0
(assuming we're n
Tim Peters added the comment:
Not a good idea in general - this rounding mode is _mostly_ "to zero", and
isn't intended for chains of operations. I don't believe I've ever seen it used
in a real program, so the current "no example at all" is a
Tim Peters added the comment:
I'll add that the rounding mode is intended to ease emulating fixed-point
arithmetic. The decimal spec claimed that was a goal, but there really isn't
any direct support for saying, e.g., "I want two digits after the decimal
point". Only
Tim Peters added the comment:
I agree with closing this - I don't know of real use cases either.
Serhiy, essentially all LSD radix sorts are stable, and rely on that for their
own correctness. MSD radix sorts vary.
--
___
Python tracker
&
Tim Peters added the comment:
Bad news: on Windows, exp2(x) is way worse then pow(2, x). Here I changed the
loop of Mark's little driver like so:
differ = really_bad = 0
worst = 0.0
for n in range(100_000):
x = random.uniform(-1000.0, 999.0) + random.random()
Tim Peters added the comment:
Across millions of tries, same thing: Windows exp2 is off by at least 1 ulp
over a third of the time, and by over 2 ulp about 3 times per million. Still
haven't seen pow(2, x) off by as much as 0.52 ulp.
>From its behavior, it appears Windows implement
Tim Peters added the comment:
Python is a general-purpose language, and as such I believe it's inappropriate
for it to be "a leader" in adopting new PRNGs. That's for area specialists to
pioneer.
If NumPy switched, that is a good reason to evaluate this again
Tim Peters added the comment:
Function objects can be used as dict keys too. Given that, it would be _very_
surprising if generator-iterators weren't. I don't really see a good point to
leaving this open. Live with it - it's a feature ;-)
--
no
Tim Peters added the comment:
What makes you think generator-iterator objects are mutable?
--
___
Python tracker
<https://bugs.python.org/issue38769>
___
___
Tim Peters added the comment:
Yes, what Steven said. All kinds of functions (including, but not limited to,
generator-iterators) are compared by object identity, nothing at all about
internal state. The contract of hash() is that if a == b, then we must have
that hash(a) == hash(b) too
Tim Peters added the comment:
Please be explicit: exactly which functions are you talking about, and exactly
what do you want them to do instead. Since, best I can tell, this is the first
complaint of its kind, it's a pretty safe bet people can't guess what you want
;-)
Note
Tim Peters added the comment:
Raymond, I think you've tricked yourself ;-) The prototype for C's duoble modf
is
double modf(double x, double *intptr);
Yes, after the call *intptr is an exact integer, but in the double format.
>>> math.modf(1e300)
(0.0, 1e+300)
I don&
Tim Peters added the comment:
Thanks for the NumPy discussion link, Mark! Did that set a world record for an
issue report's length? ;-) Not complaining - it's a very high quality and
informative discussion.
I'd be comfortable adopting whichever PRNGs numpy uses. n
Tim Peters added the comment:
I'm taking Raymond's advice to close this for now. The issue tracker isn't the
right place to work out ideas - python-ideas is far better for that
(StackOverflow isn't a good place for that either - StackOverflow is best for
when you have
Tim Peters added the comment:
There are a number of "obvious" properties that should obtain, given the
intended meaning of weights:
- An input with weight 0 should never be returned.
- The distribution shouldn't be affected by adding a new input with weight 0.
- The distrib
Tim Peters added the comment:
This behavior is intended and expected, so I'm closing this.
As has been explained, in any kind of function (whether 'lambda' or 'def'), a
non-local variable name resolves to its value at the time the function is
evaluated, not the v
New submission from Tim Gates :
There is a small typo in Lib/test/test_statistics.py.
Should read translation rather than tranlation.
--
assignee: docs@python
components: Documentation
messages: 358063
nosy: docs@python, timgates42
priority: normal
pull_requests: 16995
severity: normal
New submission from Tim Gates :
In "Lib/test/test__locale.py" the text should read thousands rather than
thousauds.
--
messages: 358134
nosy: timgates42
priority: normal
severity: normal
status: open
title: Small typo in Lib/test/test__locale.py: thousauds -&
Change by Tim Gates :
--
keywords: +patch
pull_requests: +17020
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17544
___
Python tracker
<https://bugs.python.org/issu
Tim Peters added the comment:
Closing as Mark suggested, but as "not a bug" rather than "won't fix". That
floats aren't totally ordered is a consequence of IEEE 754 semantics, not
Python's whim. As Mark said, if people want a total_ordering function for
Tim Peters added the comment:
Marco, your
> I suppose the sorting function checks if the objects of
> the iterable are minor that another object
was incoherent to me. No idea what "are minor that another object" could
possibly mean.
As Mark explained, the mathema
Tim Peters added the comment:
Ah, so you're proposing a hack that would catch some, but not all, cases where
a total ordering doesn't exist. Why? The issue tracker isn't a suitable place
to discuss it regardless, so if you want to pursue it I'd suggest taking it to
p
Tim Peters added the comment:
Sorry, but I'm not replying here any more: the issue tracker is not for asking
questions or brainstorming ideas. Take this to python-ideas, please. If a
concrete proposal that gains traction results, _then_ the issue tracker may be
an appropriate place
Tim Burke added the comment:
Note that because http.server uses http.client to parse headers [0], this can
pose a request-smuggling vector depending on how you've designed your system.
For example, you might have a storage system with a user-facing HTTP server
that is in char
Tim Peters added the comment:
Long ago I thought about adding "a buffer in front of" CPython's cyclic gc:
newly tracked items would be added there, and not participate in cyclic gc at
all until a collection passed.
For example, break the youngest generation into parts A &
501 - 600 of 2346 matches
Mail list logo
