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 the i
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 illust
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 complexi
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 o
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 cop
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/pyth
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:
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 se
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. Up
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 a
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/is
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:
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
Stefan Behnel added the comment:
Duplicate of issue 9521 (and issue 24287).
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> xml.etree.ElementTree skips processing instructions when parsing
___
Py
Stefan Behnel added the comment:
New changeset c6a7bdb356835c9d7513b1ea6846683d446fe6c3 by Stefan Behnel in
branch 'master':
bpo-20928: support base-URL and recursive includes in etree.ElementInclude
(#5723)
https://github.com/python/cpython/commit/c6a7bdb356835c9d7513b1ea684668
Stefan Behnel added the comment:
I think setting "xml:base" from ElementInclude is worth another ticket.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8
___
Pyt
Change by Stefan Behnel :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
Agreed that both should behave the same.
And, we should finally decide whether this should really be changed or not. The
current behaviour is counter-intuitive, but it's been like that forever and
lots of code depends on it in one way or anothe
Stefan Behnel added the comment:
Not so quick. :) You're probably aware of the details, but still, let me state
clearly what this is about, to make sure that we're all on the same page here.
(I'm also asking in Serhiy, because he did quite some work on ET in the past
and has
Stefan Behnel added the comment:
I think we did it wrong in issue 17582. Parser behaviour is not a reason why
the *serialisation* should modify the content.
Luckily, fixing this does not impact the C14N serialisation (which aims to
guarantee byte identical serialisation), but it changes the
Stefan Behnel added the comment:
FWIW, it seems reasonable to have a protocol for this.
--
___
Python tracker
<https://bugs.python.org/issue38225>
___
___
Pytho
Stefan Behnel added the comment:
Cython doesn't interfere with the C compiler setup in any way, that's left
to distutils/setuptools (and the user).
--
___
Python tracker
<https://bugs.python.o
Stefan Schukat added the comment:
@Batuhan the error does not appear anymore in at least Python 3.6.1
>>> import os
>>> nPath = os.path.join(os.environ["windir"], "notepad.exe")
>>> os.spawnv(os.P_NOWAIT, nPath, []) # or os.spawnv(os.P_NOWAIT,
New submission from Stefan Holek :
In Python 3.8 the default start method has changed from fork to spawn on macOS.
https://docs.python.org/3/whatsnew/3.8.html#multiprocessing
get_all_start_methods() says: "Returns a list of the supported start methods,
the first of which is the de
Change by Stefan Behnel :
--
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issue39432>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<https://bugs.python.org/issue39432>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +17536
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18150
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue39432>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
nosy: +steve.dower
___
Python tracker
<https://bugs.python.org/issue39432>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 = list
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
Stefan Pochmann added the comment:
Oh right. The times are correct, I just summarized wrongly there.
--
___
Python tracker
<https://bugs.python.org/issue39
Stefan Behnel added the comment:
Ok, this is merged into 3.9. To which versions should we backport it?
Definitely 3.8, definitely not 3.5, probably not 3.6 (since it's not a security
issue). Ned, what about 3.7?
--
nosy: +ned.deily
stage: patch review -> backpor
Stefan Behnel added the comment:
I agree that SystemError is the wrong response. Whether it needs to be
AttributeError – probably fine to consider this an implementation detail.
TypeError also seems ok in at least some of the cases. I think we should widen
the code to expect some kind of
Stefan Krah added the comment:
With _pydecimal the memory also grows very slowly (I didn't have the patience
to wait for MemoryError).
I'm pretty sure decNumber also does the same, it's just easier to implement
and does not slow down division for small numbers.
libmpde
Stefan Krah added the comment:
MAX_PREC is chosen so that 5*MAX_PREC does not overflow 32-bit or 64-bit signed
integers. This eliminates many overflow checks for the exponent.
Updating the exponent is (perhaps surprisingly) quite performance sensitive,
that's why the 32-bit build doe
Stefan Krah added the comment:
The feature would be nice to have; however, if you choose the precision to
match the amount of available RAM things work (I have 8GB here, one word in the
coefficient has 19 digits for the 4 bit version):
>>> from decimal import *
>>&
Stefan Krah added the comment:
> This isn't purely academic. The `decimal` docs, at the end:
Yes, that is a good point. I think for libmpdec I'll just do a trial divmod if
prec > BIGNUM_THRESHOLD.
> Perhaps the only thing to be done is to add words to t
New submission from Stefan Krah :
As mentioned in the PR, I don't see sufficient evidence that backticks are
legacy. So I'll close this.
--
assignee: -> skrah
nosy: +skrah
resolution: -> rejected
stage: patch review -> resolved
sta
Stefan Behnel added the comment:
Your patch looks good to me. Could you please add (or adapt) the tests and then
create a PR from it? You also need to write a NEWS entry for this change, and
it also seems worth an entry in the "What's new" document.
https://devguide.python
Stefan Krah added the comment:
The change looks reasonable, but unfortunately this is a long-standing
behavior that originates from before the Python-3.3 memoryview rewrite.
It is also present in 2.7 (the previous implementation) and documented
in 3.3:
https://docs.python.org/3/library
Stefan Behnel added the comment:
New changeset 5bf58cef151249f1cca92166d1b70693348da9d8 by Miss Islington (bot)
in branch '3.8':
bpo-39432: Implement PEP-489 algorithm for non-ascii "PyInit_*" symbol names in
distutils (GH-18150) (GH-18546)
https://github.com/p
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Stefan Krah :
--
nosy: skrah
priority: normal
severity: normal
status: open
title: Azure Pipelines PR broken
___
Python tracker
<https://bugs.python.org/issue39
New submission from Stefan Krah :
There is no status report, no details link and manually committing is
prohibited:
https://github.com/python/cpython/pull/18569
--
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
Closing and reopening the PR helped.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Stefan Krah added the comment:
Re-opening this issue, Azure fails too often:
https://github.com/python/cpython/pull/18577
https://dev.azure.com/Python/cpython/_build/results?buildId=58220&view=logs&j=c83831cd-3752-5cc7-2f01-8276
Change by Stefan Krah :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue39701>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +17951
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18581
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
Fortunately libmpdec raises MemoryError almost instantaneously, so the PR
retries
the affected operations with estimated upper bounds for exact results without
slowing down the common case.
The docs still need updating because people will still wonder why 1
Stefan Krah added the comment:
BTW, this PR implements the invariant:
"If there exists an exact result at a lower precision, this
result should also be returned at MAX_PREC (without MemoryError)".
So non-integer powers are left out, since _decimal has no notion
of exact non-inte
New submission from Stefan Krah :
The automated code coverage on GitHub is quite inaccurate and needlessly flags
PRs as red.
I'd prefer to make this opt-in.
--
messages: 362367
nosy: skrah
priority: normal
severity: normal
status: open
title: Disable code cov
Stefan Krah added the comment:
New changeset 90930e65455f60216f09d175586139242dbba260 by Stefan Krah in branch
'master':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581)
https://github.com/python/cpython/commit/90930e65455f60216f09d175586139
Stefan Krah added the comment:
New changeset c6f95543b4832c3f0170179da39bcf99b40a7aa8 by Miss Islington (bot)
in branch '3.7':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581)
(#18585)
https://github.com/python/cpyt
Stefan Krah added the comment:
New changeset b6271025c640c228505dc9f194362a0c2ab81c61 by Miss Islington (bot)
in branch '3.8':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581)
(#18584)
https://github.com/python/cpyt
Stefan Krah added the comment:
I'd definitely disable the automatic comment and prefer that the build
happens on buildbot.python.org rather than affecting the GitHub build
status.
--
___
Python tracker
<https://bugs.python.org/is
Stefan Krah added the comment:
Vedran, msg362365 is meant to say:
"This PR implements $SOMEWHAT_MATHEMATICAL_SPEC except for inexact power."
Had I put the caveat inside the statement as well, the message would have been:
"Thi
Stefan Krah added the comment:
"So non-integer powers are left out" in isolation would indeed be
wrong, but actual sentence is unambiguously qualified with:
"... since _decimal has no notion of exact non-integer powers yet.",
which clearly states that exact non-inte
Change by Stefan Krah :
--
pull_requests: +17961
pull_request: https://github.com/python/cpython/pull/18594
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
Updated docs:
https://github.com/python/cpython/pull/18594
The PR uses some of Tim's suggestions while also explaining how to
calculate the amount of memory used in a single large decimal.
Hopefully it isn't too much i
Stefan Krah added the comment:
They are allowed failures but the build is still marked in red:
https://github.com/python/cpython/pull/18567
So if you look at the front page you have to click through red results
only to find that the reason is code coverage
Stefan Krah added the comment:
New changeset a025d4ca99fb4c652465368e0b4eb03cf4b316b9 by Stefan Krah in branch
'master':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic (#18594)
https://github.com/python/cpython/commit/a025d4ca99fb4c652465368e0b4eb0
Stefan Krah added the comment:
New changeset 00e45877e33d32bb61aa13a2033e3bba370bda4d by Miss Islington (bot)
in branch '3.7':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic
(GH-18594) (#18596)
https://github.com/python/cpyt
Stefan Krah added the comment:
New changeset d6965ff026f35498e554bc964ef2be8f4d80eb7f by Miss Islington (bot)
in branch '3.8':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic
(GH-18594) (#18597)
https://github.com/python/cpyt
Stefan Krah added the comment:
libmpdec and the docs are done, the question remains what to do with
decimal.py.
It has the same behavior, but I don't think users are running
decimal.py with very large precisions.
Anyway, unassigning myself in case anyone else wants to work on a
Change by Stefan Krah :
--
stage: patch review -> resolved
___
Python tracker
<https://bugs.python.org/issue39576>
___
___
Python-bugs-list mailing list
Un
Change by Stefan Krah :
--
pull_requests: +17981
pull_request: https://github.com/python/cpython/pull/18616
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
New changeset b76518d43fb82ed9e5d27025d18c90a23d525c90 by Stefan Krah in branch
'master':
bpo-39576: Clarify the word size for the 32-bit build. (#18616)
https://github.com/python/cpython/commit/b76518d43fb82ed9e5d27025d18c90
Stefan Krah added the comment:
New changeset 24c570bbb82a7cb70576c253a73390accfa7ed78 by Miss Islington (bot)
in branch '3.7':
bpo-39576: Clarify the word size for the 32-bit build. (GH-18616) (#18617)
https://github.com/python/cpython/commit/24c570bbb82a7cb70576c253a73390
Stefan Krah added the comment:
New changeset c6ecd9c14081a787959e13df33e250102a658154 by Miss Islington (bot)
in branch '3.8':
bpo-39576: Clarify the word size for the 32-bit build. (GH-18616) (#18618)
https://github.com/python/cpython/commit/c6ecd9c14081a787959e13df33e250
Stefan Krah added the comment:
For me even a mail with a single line would be too much. I can filter that in
my mail client but not on GitHub.
Speaking about that, I also don't want to get mail from Bevedere stating that
I, in fact, have signed a CLA any time I open
Stefan Krah added the comment:
Before I look at the example code: Can you also reproduce this with
Python 3.6? The threading code in _decimal was changed to a ContextVar
in 3.7.
There's a high chance though that the problem is in the c++ module.
--
nosy: +
Stefan Krah added the comment:
I've briefly looked at the zip archive. Without going much into
the C++ module as a whole, this should not be done:
gil_unlocker.UnlockGILAndSleep()
self.val = decimal.Decimal(1) / decimal.Decimal(7)
gil_unlocker.UnlockGILAndSleep()
If you w
Change by Stefan Krah :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39776>
___
___
Stefan Krah added the comment:
I built your example with 3.6:
git clone https://github.com/pybind/pybind11
wget https://bugs.python.org/file48923/decimal_crash.zip
unzip decimal_crash.zip
git checkout v3.6.7
./configure --with-pydebug
make
g++ -std=c++11 -pthread -Wno-unused-result -Wsign
Stefan Krah added the comment:
This is 3.6.7, compiled --with-pydebug:
$ ./main
Aborted (core dumped)
(gdb) bt
#0 0x7f9974077428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x7f997407902a in __GI_abort () at abort.c:89
#2 0x0056e2d1 in
Stefan Krah added the comment:
Note that my pybind11 is from GitHub master, it can also be a pybind11
issue.
It is interesting that you cannot reproduce your original issue with
3.6, so I'm reopening this issue.
I think we need a reproducer without pybind11 though, could you
tweak Pro
Change by Stefan Krah :
--
resolution: not a bug ->
stage: resolved ->
___
Python tracker
<https://bugs.python.org/issue39776>
___
___
Python-bugs-list
Stefan Krah added the comment:
Regarding *my* issue, it could be anything, e.g. a missing call to
PyEval_InitThreads() in 3.6:
"Changed in version 3.7: This function is now called by Py_Initialize(), so you
don’t have to call it yourself anymore."
This is why we need to eliminat
Stefan Krah added the comment:
> With python 3.7.3 without https://github.com/python/cpython/pull/5278 works
> just fine.
Thanks, I'm now getting the same results as you. Looking at the smaller
test case, I also agree that it should work (as it did in 3.6).
Stefan Behnel added the comment:
New changeset dc04a0571e362cd3de040771d7705cb107ae26fc by Henry Harutyunyan in
branch 'master':
bpo-37534: Allow adding Standalone Document Declaration when generating XML
documents (GH-14912)
https://github.com/python/cpyt
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Stefan Krah :
#39776 has shown that it is hard to understand the interaction between
ContextVars and threading in embedded scenarios.
I want to understand the code again, so I'm adding back a compile time
option to enable the thread local context that was present pri
Change by Stefan Krah :
--
assignee: -> skrah
components: +Extension Modules
stage: -> needs patch
type: -> behavior
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
Also, when I'm debugging things like #39776, I don't want to
switch between Python versions.
--
___
Python tracker
<https://bugs.python.o
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=[]" &
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
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +18064
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18702
___
Python tracker
<https://bugs.python.org/issu
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,
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:
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 Krah added the comment:
New changeset 815280eb160af637e1347213659f9236adf78f80 by Stefan Krah in branch
'master':
bpo-39794: Add --without-decimal-contextvar (#18702)
https://github.com/python/cpython/commit/815280eb160af637e1347213659f92
Change by Stefan Krah :
--
pull_requests: +18072
pull_request: https://github.com/python/cpython/pull/18713
___
Python tracker
<https://bugs.python.org/issue39
Change by Stefan Krah :
--
pull_requests: +18074
pull_request: https://github.com/python/cpython/pull/18714
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
New changeset 4d7012410cf4f91cbca4c406f4747289c2802333 by Stefan Krah in branch
'3.8':
[3.8] bpo-39794: Add --without-decimal-contextvar (GH-18702)
https://github.com/python/cpython/commit/4d7012410cf4f91cbca4c406f47472
Stefan Krah added the comment:
New changeset c4ca1f8f24118dc5c29e16118fb35a13963af290 by Stefan Krah in branch
'3.7':
[3.7] bpo-39794: Add --without-decimal-contextvar (GH-18702)
https://github.com/python/cpython/commit/c4ca1f8f24118dc5c29e16118fb35a
Change by Stefan Krah :
--
nosy: +boytsovea
___
Python tracker
<https://bugs.python.org/issue39794>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 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
801 - 900 of 4949 matches
Mail list logo
