New submission from Stefan Pochmann :
The signatures for the versions without "_right" suffix are missing the key
parameter:
bisect.bisect_right(a, x, lo=0, hi=len(a), *, key=None)
bisect.bisect(a, x, lo=0, hi=len(a))ΒΆ
bisect.insort_right(a, x, lo=0, hi=len(a), *, key=None)
bisect.i
Stefan Pochmann added the comment:
The error occurs when you do code.strip()[0] when code is " ", not "u2".
--
nosy: +Stefan Pochmann
___
Python tracker
<https://bug
Stefan Pochmann added the comment:
Ok, thanks, had somewhat expected that, as the multimode proposal was rather
clearly better but the mode proposal not so much.
--
___
Python tracker
<https://bugs.python.org/issue45
New submission from Stefan Pochmann :
This test:
def test_counter_data(self):
# Test that a Counter is treated like any other iterable.
data = collections.Counter([1, 1, 1, 2])
# Since the keys of the counter are treated as data points, not the
# counts
Stefan Pochmann added the comment:
(somehow the benchmark script didn't get attached, trying again)
--
Added file: https://bugs.python.org/file50453/multimode_mode.py
___
Python tracker
<https://bugs.python.org/issue45
New submission from Stefan Pochmann :
The current implementation is:
def multimode(data):
counts = Counter(iter(data)).most_common()
maxcount, mode_items = next(groupby(counts, key=itemgetter(1)), (0, []))
return list(map(itemgetter(0), mode_items))
The most_common() does
Stefan Pochmann added the comment:
Turns out for n=100_000, k=50_000, about 87% of my factors are 1, so they don't
even need to be turned into Python ints for multiplication, improving the
multiplication part to 3.05 ms. And a C++ version to produce the factors took
0.85 ms. Updated
Stefan Pochmann added the comment:
And for Raymond's case 4), about running very long and not responding to
SIGINT, with n=1_000_000 and k=500_000:
150.91 seconds math.comb(n, k)
39.11 seconds factorial(n) // (factorial(k) * factorial(n-k))
0.40 seconds mycomb(n, k)
0.14 seconds
Stefan Pochmann added the comment:
I wrote a Python solution ("mycomb") that computes comb(100_000, 50_000)
faster, maybe of interest:
1510.4 ms math.comb(n, k)
460.8 ms factorial(n) // (factorial(k) * factorial(n-k))
27.5 ms mycomb(n, k)
6.7 ms *estimation* for mycomb
Stefan Pochmann added the comment:
Just saw that it's in copy.py's docstring as well:
"This version does not copy types like module, class, function, method,
nor stack trace, stack frame, nor file, socket, window, nor array, nor
any similar types."
https://github.com/python/cpython
New submission from Stefan Pochmann :
The doc https://docs.python.org/3/library/copy.html says:
"This module does not copy types like module, method, stack trace, stack frame,
file, socket, window, array, or any similar types."
But it does copy arrays just fine:
import c
Stefan Pochmann added the comment:
> This is already faster in pure Python than list.sort() for cases like:
Seems to depend on the system, it's slower on my laptop but faster on GCE:
Python 3.10.0 on my laptop:
7.42 s lexisort
6.83 s sort
5.07 s groupsort
Python 3.9.2 on Goo
Stefan Pochmann added the comment:
Yes, I'm more familiar with the issue in the context of strings or lists. Your
example of strings like "'x' * 10_000 + str(i)" looks like something I almost
certainly used before as counterexample to someone's time complexity claim :-)
I t
Stefan Pochmann added the comment:
> It's not surprising the 2nd positions are rarely equal _given_ that the
> universe has been reduced to the 100 tuples with the same first element.
Yes, exactly.
> In any case, I don't see the point to this exercise ;-)
Just to illustrate why I
Stefan Pochmann added the comment:
I see you mentioned that PyObject_RichCompareBool(..., Py_EQ) might be faster
for example because it checks identity. Why not do an identity check before the
ms->tuple_elem_compare calls? Too expensive and rarely successful?
> Extending th
Stefan Pochmann added the comment:
Hmm. What do you think about using "<" inside the loop for the remaining tuple
elements as well? It's even less likely that both the first and the second
elements are equal.
When the second elements differ, this saves 0.5 PyObject_RichCompareB
Stefan Pochmann added the comment:
Ok, I agree, the change only possibly "breaks" expectations that were already
broken (including my naive sorted-vs-minmax).
Yes, I know sort itself only asks `<` (I've actually read most of its code and
all its documentation). That's why I
Stefan Pochmann added the comment:
I misinterpreted you then, sorry. I guess also because 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'd say the inc
Stefan Pochmann added the comment:
> What justifies "shouldn't"?
I based that on your old comments. Looked like tuple comparison results in
sorting shouldn't differ from tuple comparison results elsewhere. I had
actually proposed this exact method in a comment under your
Stefan Pochmann added the comment:
That's how Elliot did it in the original proposal:
https://bugs.python.org/issue28685
Back then you pointed out that "Else we can assume u[0] == v[0]" isn't true for
float('nan') values:
https://github.com/python/cpython/pull/582#issuecomment
Change by Stefan Pochmann :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue45346>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Stefan Pochmann :
Python consistently says true/false, not truthy/falsy. But a few "truthy" have
crept in now:
https://github.com/python/cpython/search?q=truthy
- Two in Doc/reference/compound_stmts.rst
- One in Doc/library/ast.rst
- One in Lib/test/test_
Stefan Pochmann added the comment:
I misspoke. I do the insertions at -1 and -500 not on the same list but each on
a fresh list (of length 2**20+1).
--
___
Python tracker
<https://bugs.python.org/issue39
Stefan Pochmann added the comment:
I think I have a decent way to isolate the memmove vs for-loop times, in Python
code. Here are example results, five rounds of inserting with list.insert or
with slice assignment. The times for each of the two ways are pretty stable:
insertslice
Change by Stefan Pochmann :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue39801>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Pochmann added the comment:
I have better benchmarks now and am trying some more, though I guess we roughly
agree about when memmove is faster and when it's slower but that the real
question is how large the common case is.
Do you know where I can find those past investigations
Stefan Pochmann added the comment:
Good point, Tim. Although binarysort really moves very few slots (I think at
most 62, and average like 13). That might not be representative for how people
use list.insert, either. I think I mainly use it for the mentioned case of a
"self-sorting
Stefan Pochmann added the comment:
Benchmarking with two *Python* versions of bisect.insort, the "insert" version
takes 1.08 seconds to insort the shuffled range(10**5) while the slice
assignment version only takes 0.46 seconds:
from timeit import timeit
import random
from bis
Stefan Pochmann added the comment:
I believe it also affects bisect.insort, which I occasionally use when I need a
"self-sorting list" (I can't easily test it, as I'm not set up to modify the C
version of bisect.insort).
And also the popular sortedcontainers package, wh
Change by Stefan Pochmann :
--
title: list.insert is slow due to manual memmove -> list.insert is slow, likely
due to manual memmove
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Pochmann :
Using a list's insert function is much slower than using slice assignment:
> python -m timeit -n 10 -s "a=[]" "a.insert(0,0)"
10 loops, best of 5: 19.2 usec per loop
> python -m timeit -n 10 -s "a=[]" "
Stefan Pochmann added the comment:
Oh right. The times are correct, I just summarized wrongly there.
--
___
Python tracker
<https://bugs.python.org/issue39
Change by Stefan Pochmann :
--
title: reversed(mylist) much slower on Python 3.8.1 32-bit for Windows ->
reversed(mylist) much slower on Python 3.8 32-bit for Windows
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Pochmann :
Somehow `reversed` became much slower than `iter` on lists:
List with 1,000 elements:
> python -m timeit -s "a = list(range(1000))" "list(iter(a))"
5 loops, best of 5: 5.73 usec per loop
> python -m timeit -s "a = li
Stefan Pochmann <stefan.pochm...@gmail.com> added the comment:
And `bytearray`.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Stefan Pochmann <stefan.pochm...@gmail.com> added the comment:
Yes, there's also `array.array`.
--
nosy: +Stefan Pochmann
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Stefan Pochmann <stefan.pochm...@gmail.com>:
The itertools page https://docs.python.org/3.6/library/itertools.html says
"Combinatoric generators:" above the table with product(), permutations(), etc.
But as far as I understand, they're not generators and th
New submission from Stefan Pochmann:
functools.reduce has a parameter called "iterable" and it only needs to be an
iterable, not a sequence.
The paragraph documenting it says "sequence" instead of "iterable" six times:
https://docs.python.org/3/library/functools.h
New submission from Stefan Pochmann:
Python 3.6 makes it sound like maps aren't iterable:
>>> map(str, *map(int, [[]]))
Traceback (most recent call last):
File "<pyshell#0>", line 1, in
map(str, *map(int, [[]]))
TypeError: type object argument after * must be a
New submission from Stefan Pochmann:
The notes at
https://docs.python.org/3/library/stdtypes.html#boolean-operations-and-or-not
say that `or` "only evaluates the second argument if the first one is False"
and that `and` "only evaluates the second argument if the first one is
Stefan Pochmann added the comment:
The page also contains many references like "As repr(), return a string
containing..." where the "()" should be removed.
--
___
Python tracker <rep...@bugs.python.org>
<http
New submission from Stefan Pochmann:
About https://docs.python.org/3/library/functions.html: The title "Built-in
Functions", the table header "Built-in Functions" and the "functions" in the
URL all suggest that what's on this page are functions. But many thi
42 matches
Mail list logo
