Stefan Krah added the comment:
> You'll have to let the readers of this thread judge that for themselves.
Ask Cowlishaw or the mpfr developers to read this thread.
As for politeness, msg372581 was entirely polite and directly answered
by an inappropriate and petulant msg372584.
Thi
Stefan Krah added the comment:
Since this is an ongoing problem: When I submitted the decNumber
patches to Cowlishaw, he asked me if I would be interested in
maintaining decNumber. I declined at the time due to time constraints.
Had I accepted, I'd control 2/3 of the decimal market now
Stefan Krah added the comment:
Yeah, I already felt a bit guilty about adding you -- it could be a compiler
bug or an actual overflow. My bet is also that the reordering exposes an
existing overflow. The reordering itself certainly looks correct to me.
When I have time, I'll try to
Stefan Krah added the comment:
New changeset 604d95e235d86465b8c17f02095edcaf18464d4c by Lawrence D'Anna in
branch 'master':
bpo-41100: fix _decimal for arm64 Mac OS (GH-21228)
https://github.com/python/cpython/commit/604d95e235d86465b8c17f02095edcaf18464d4c
Stefan Krah added the comment:
It looks like a compiler bug (line numbers are after macro expansion):
#0 0x006ea678 in _PyEval_EvalFrameDefault (f=0x886d20
<_PyRuntime+352>, throwflag=-8) at Python/ceval.c:35554
#1 0x0057167b in _PyEval_EvalCodeWithName (_co=0x
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +20395
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21243
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
New changeset 1648c99932f39f1c60972bb114e6a7bd65523818 by Stefan Krah in branch
'master':
bpo-41161 Add news entry for libmpdec-2.5.0 (GH-21243)
https://github.com/python/cpython/commit/1648c99932f39f1c60972bb114e6a7
Stefan Krah added the comment:
New changeset c84d3fe6b3301c7fd4a82e63fb4d545a7b9df84b by Miss Islington (bot)
in branch '3.9':
bpo-41161 Add news entry for libmpdec-2.5.0 (GH-21243) (#21244)
https://github.com/python/cpython/commit/c84d3fe6b3301c7fd4a82e63fb4d54
Change by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
After seeing people from a certain company defend a bizarre and
broken stack with falsehoods, I apologize to Inada-san and now
assume that he had a similar experience.
--
nosy: +skrah
___
Python tracker
<ht
Stefan Krah added the comment:
Though code objects do not concern me directly, as the author of
memoryview I now concur with Inada-san that we should not support
hacks in the Python code base that benefit a single company.
--
___
Python tracker
Stefan Krah added the comment:
For clarification, the incident I referred to is entirely unrelated to *this*
issue: Of course Dino Viehland has been rational, friendly and competent.
I wanted to point out that people might have had a formative experience
*elsewhere
Change by Stefan Behnel :
--
versions: -Python 3.7
___
Python tracker
<https://bugs.python.org/issue39960>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
I think we missed the train for fixing 3.7 (which was questionable anyway), but
I added a test, so it's ready for merging into 3.8+ (minus merge conflicts for
the test in 3.8, probably).
--
___
Python tr
Stefan Krah added the comment:
It is instructive that ArchLinux quietly and professionally packaged
mpdecimal-2.5.0 hours after the release:
https://www.archlinux.org/packages/?sort=&q=mpdecimal&maintainer=&flagged=
This is in stark contrast with Python-dev, where a main
Stefan Krah added the comment:
I was the one being attacked in this issue, while releasing a zero
fault library whose release procedures resemble those found in
avionics software.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
Christian, you are also completely ignoring the original attack
of Anthony, so you are biased and there is no point continuing.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Stefan Krah :
--
components: +Extension Modules
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
I was accused of breaking the release, which is false. It is outside
of a release manager's authority to claim that an *experimental* and
*nightly* build that uses a flag in an unintended manner needs counts
as bre
Stefan Krah added the comment:
Raymond, Mark, Antoine: If you think this should be reverted, I'll
revert it.
--
nosy: +mark.dickinson, pitrou, rhettinger
___
Python tracker
<https://bugs.python.org/is
Stefan Krah added the comment:
> backwards incompatible changes.
It is not a backwards incompatible change. Slamming a 3.9 into
a nightly build has never been supported.
--
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
Since this issue has been brought to the attention of the CoC
committee. Here is how *I* report issues:
https://bugs.python.org/issue40223#msg372578
https://bugs.python.org/issue40223#msg372637
https://github.com/google/sanitizers/issues/1257
Note
Stefan Krah added the comment:
Matthias, to tell the truth, I was never sure about the soname.
I read this:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
"""
The SONAME and binary package name need not, and indeed normally should not,
change if new interface
Stefan Krah added the comment:
> In the mean time may I request that you follow our protocol for code review.
Ah, who reviews libffi? It is just updated. Not counting the thousands of
other cases people commit unreviewed, like in changing the C-API.
And no, Christian, that is
Stefan Krah added the comment:
> both 3.8 and 3.9 have to be available on the systems for the transition
> period.
If sonames can be incremented for libraries even if they are ABI compatible,
how about using up as many as you need for the Debian
package? Next time when I release mpd
Stefan Krah added the comment:
Łukasz, which one is nicer?
> reverting this patch passes all the tests, what's the motivation and why were
> there no code reviews for this?
or:
> Yeah, I already felt a bit guilty about adding you -- it could be a compiler
> bug or an act
Stefan Krah added the comment:
Finally, about the Debian issue, of course you could also link 3.8
against the static lib.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
> Finally, while Raymond and Antoine are welcome to voice their opinions on the
> matter, your change is landing in 3.9.0b4 which I'm about to announce. So we
> won't be reverting it. In the future let's make sure we stick to the rele
Stefan Krah added the comment:
How witty!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
Christian Heimes has expressed an interest (quite rudely) in unreviewed commits
elsewhere. I wonder if that applies to everyone regardless of employer.
--
nosy: +christian.heimes, skrah
___
Python tracker
<ht
Stefan Krah added the comment:
Ah, I see that the subject has already been answered in the negative:
https://discuss.python.org/t/make-code-review-mandatory/4174
He must have forgotten.
--
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
Agreed, and it's even slightly worse with the ROUND_FLOOR special case:
>>> c.rounding = ROUND_FLOOR
>>> +Decimal("-0")
Decimal('-0')
>>>
That's why there are three slightly different method
Stefan Krah added the comment:
I have no opinion about this commit (I did not benchmark anything,
but I wouldn't be surprised if Victor did).
I do have the opinion that unreviewed commits occur quite frequently
and nearly every committer has made some (or a lot), including the
committer
Stefan Krah added the comment:
> In any case, I would have had a hard time giving a competent opinion on this
> issue.
Essentially it's a really simple Linux packaging issue for the
external libmpdec. To have the exact same behavior for the external
libmpdec as for the includ
Stefan Krah added the comment:
Thanks for taking a look, Antoine.
IIRC, the version pinning already accommodates Debian:
#if !defined(MPD_VERSION_HEX) || MPD_VERSION_HEX < 0x0205
#error "libmpdec version >= 2.5.0 required"
#endif
In the first libmpdec versions,
Change by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue41215>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
pull_requests: +20487
pull_request: https://github.com/python/cpython/pull/21339
___
Python tracker
<https://bugs.python.org/issue39
Stefan Behnel added the comment:
New changeset 8912c182455de83e27d5c120639ec91b18247913 by scoder in branch
'3.8':
bpo-39960: Allow heap types in the "Carlo Verre" hack check that override
"tp_setattro()" (GH-21092) (GH-21339)
https://gi
Stefan Behnel added the comment:
Fixed in 3.8+. Closing.
Thanks for the feedback.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
As noted in the first message of this thread, the sqrt-max-prec feature
(requested by Mark and Tim) was already in 3.9 long before the beta
freeze.
I'm not sure why this is not clear from the original message.
That fix is safe for Python, but not fo
Stefan Krah added the comment:
> The standalone libmpdec had to be updated, and was updated according
to the Debian-friendly way requested by Matthias himself.
Not updated, of course the sqrt-max-prec *had never been* in
the standalone libmpdec, it is new in 2.
Stefan Krah added the comment:
More than that, I had *promised* Matthias privately to release a
new libmpdec for the sqrt-max-prec feature a couple of months ago.
I request that further packaging issues will be dealt with primarily
by Matthias and myself
Stefan Krah added the comment:
A brief note for Victor that *nothing* was directed against him. On
the contrary, msg372995 was supporting him in case the commit had
actually been unreviewed, which it apparently wasn't. Sorry for
jumping on the bandwagon there.
> PEP 620 for the over
Stefan Krah added the comment:
s/PyPy as a bottleneck/the C-API as a bottle neck for PyPy/
--
___
Python tracker
<https://bugs.python.org/issue39542>
___
___
Stefan Krah added the comment:
Thank you for the report, I'll add the define or remove UNUSED in 3.9
and 3.10.
3.8 is still supposed to use libmpdec-2.4.2, though it would be
harmless to use libmpdec-2.5.0.
Are you planning to use libmpdec-2.5.0 with 3.8?
--
assignee: -&g
Stefan Krah added the comment:
New changeset 015efdbef7454a522e88cd79ba2b4cd77a5fb2a2 by Felix Yan in branch
'master':
bpo-41302: Fix build with system libmpdec (GH-21481)
https://github.com/python/cpython/commit/015efdbef7454a522e88cd79ba2b4c
Stefan Krah added the comment:
Thanks for the patch!
The integrated libmpdec-2.4.2 in Python 3.8 still has a couple of
UNUSED, so the simple approach of moving the define would not work.
It would be easy to replace the few instances of UNUSED with void
casts like in 2.5.0.
Strictly speaking
Change by Stefan Krah :
--
resolution: -> fixed
stage: patch review ->
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue41302>
___
___
Stefan Krah added the comment:
If I understand this correctly, I think this may be a duplicate of #13797.
Something like a __getbuffer__ protocol would be needed. I'm not
saying we *should* go that route, just stating the requirements
from my perspe
Stefan Krah added the comment:
Yes, let's make #13797 a superseder.
--
___
Python tracker
<https://bugs.python.org/issue41285>
___
___
Python-bugs-list m
Change by Stefan Krah :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Allow objects implemented in pure Python to export PEP 3118
buffers
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
I'm going to reclassify this as a build fix for 3.8. 3.8 promises:
#if !defined(MPD_VERSION_HEX) || MPD_VERSION_HEX < 0x02040100
#error "libmpdec version >= 2.4.1 required"
#endif
So it seems reasonable to support at least two or thr
Stefan Krah added the comment:
New changeset 16eea45fbd3b7c3d1b222b7eb7a5d7ee427f70bd by Felix Yan in branch
'3.8':
[3.8] bpo-41302: Support system libmpdec 2.5 for Python 3.8 (GH-21488)
https://github.com/python/cpython/commit/16eea45fbd3b7c3d1b222b7eb7a5d7
Stefan Krah added the comment:
Closing, thanks for all the patches!
--
stage: -> resolved
status: open -> closed
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/i
Stefan Krah added the comment:
Mark has already mentioned that setting the recursion limit to a
value higher than 2000-1 makes no sense.
Apart from that, sys.maxsize is actually documented like this:
maxsize -- the largest supported length of containers.
So it applies to Py_ssize_t
Stefan Krah added the comment:
The top level decimal.py that dispatches to either _decimal or
_pydecimal is pure Python. So perhaps these applications could
add these methods themselves:
>>> import decimal
>>> def exp(x):
... return x.exp()
...
>>> deci
Change by Stefan Krah :
--
assignee: skrah
components: Extension Modules
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a minimal decimal capsule API
versions: Python 3.10
___
Python tracker
<ht
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +20656
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21519
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Krah :
This adds a minimal decimal capsule API. As can be seen from the patch,
adding anything to decimal while doing it properly is quite labor and
testing intensive, so the intent is to *keep* the API minimal!
That said, some functions are really necessary:
1
Stefan Krah added the comment:
Closing in favor of #41324, which adds just the most important
functions.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Add a minimal decimal capsule API
___
Py
Change by Stefan Krah :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue41324>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
Also as a note for Mark and Raymond: This API is for exact conversions
and avoids the use of the context except for raising ConversionSyntax.
I'll add documentation once Antoine has tried it out for his use
Stefan Krah added the comment:
Adding Daniele Varrazzo, in case this is useful for the PostgreSQL
adapter.
--
nosy: +piro
___
Python tracker
<https://bugs.python.org/issue41
Stefan Behnel added the comment:
The problem in the test added in PR 21473 is that there is an intermediate base
type "object" in the hierarchy:
class A(type):
def __setattr__(cls, key, value):
type.__setattr__(cls, key, value)
class B:
pass
Stefan Behnel added the comment:
> intermediate base type "object" in the hierarchy
Sorry, I meant an intermediate base type "B", which inherits its setattr from
"object".
--
___
Python tracker
&l
Change by Stefan Behnel :
--
pull_requests: +20664
pull_request: https://github.com/python/cpython/pull/21528
___
Python tracker
<https://bugs.python.org/issue41
Stefan Behnel added the comment:
I pushed PR 21528 with a new proposal. See issue 41295.
--
___
Python tracker
<https://bugs.python.org/issue39960>
___
___
Pytho
Stefan Krah added the comment:
I cannot detect a speedup in test_buffer, which is a heavy user of memoryviews:
# before:
>>> a = [3.742, 3.589, 3.542, 3.495, 3.481, 3.620, 3.773, 3.755, 3.701, 3.661]
>>> sum(a) / 10
3.63589995
# after
>>> b = [3.63, 3.59
Stefan Behnel added the comment:
PR 21528 works for all four test cases that we now have (1x test_capi.py, 3x
test_descr.py).
Any comments? We need to merge a fix before Monday to meet the deadline of the
planned hotfix release.
@kam193, could you please also test that change with your
Stefan Krah added the comment:
It looks like the API would be usable, so the PR now has documentation.
--
___
Python tracker
<https://bugs.python.org/issue41
Stefan Behnel added the comment:
There have been sporadic buildbot failures in "test_asyncio" since this change,
message being "1 test altered the execution environment", e.g.
https://buildbot.python.org/all/#/builders/129/builds/1443
Could someone please check
Stefan Behnel added the comment:
> test_asyncio altered the execution environment
That happened several times before in previous builds. I think there's just a
part of the asyncio tests that is unreliable. I left a comment in issue 41273
since it might be related, the sporadic
Stefan Krah added the comment:
New changeset 10e466448f67850ed7bb2e2a4e7f017f2b050cad by Srinivas Reddy
Thatiparthy (శ్రీనివాస్ రెడ్డి తాటిపర్తి) in branch 'master':
bpo-41205: Document Decimal power 0 to the 0 (GH-21386)
https://github.com/python/cpyt
Stefan Krah added the comment:
Thanks, I can confirm that the speedup for memoryview.cast() is large in
microbenchmarks.
Still, if the speedup cannot be seen in programs like test_buffer,
the amount of code that's being added for a speedup < 5% in real
world programs is quite substan
Stefan Krah added the comment:
I'm happy with the API, except that --with-system-libmpdec is naturally
broken. So I've to release a new libmpdec, which I'd rather do soon
because I don't want to revisit this later.
Antoine has looked at the API. If anyone else has re
New submission from Stefan Krah :
This issue tracks the update of the included libmpdec to version 2.5.1.
The version includes features required for #41324.
--
assignee: skrah
components: Extension Modules
messages: 374101
nosy: skrah
priority: normal
severity: normal
status: open
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +20732
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21593
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
New changeset 9b9f1582753979f38d2fd927cddf0621a65e9ed6 by Stefan Krah in branch
'master':
bpo-41369 Update to libmpdec-2.5.1: new features (GH-21593)
https://github.com/python/cpython/commit/9b9f1582753979f38d2fd927cddf06
Stefan Behnel added the comment:
New changeset e28b8c93878072dc02b116108ef5443084290d47 by Zackery Spytz in
branch 'master':
bpo-35018: Sax parser should provide user access to lexical handlers (GH-20958)
https://github.com/python/cpython/commit/e28b8c93878072dc02b116108ef544
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
New changeset 39042e00ab01d6521548c1b7cc6554c09f4389ff by Stefan Krah in branch
'master':
bpo-41324 Add a minimal decimal capsule API (#21519)
https://github.com/python/cpython/commit/39042e00ab01d6521548c1b7cc6554
Change by Stefan Krah :
--
components: +C API -Extension Modules
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
We need more information.
Is this 64-bit AIX?
How much physical memory does the machine have?
Linux also has over-allocation and the default for ulimit is unlimited.
But it does not attempt to over-allocate such an outrageous amount of
memory.
Neither do
Stefan Krah added the comment:
Also, perhaps build Python with -bmaxdata?
https://www.enterprisedb.com/edb-docs/d/postgresql/reference/manual/11.1/installation-platform-notes.html
--
___
Python tracker
<https://bugs.python.org/issue41
Stefan Krah added the comment:
The test (size > (size_t)PY_SSIZE_T_MAX)) has nothing to do with it. Within
Python, most sizes are ssize_t, so a value larger than SSIZE_MAX is suspicious.
AIX is an unsupported platform.
Realistically, if people want AIX to be supported, someone has to g
Stefan Krah added the comment:
> Core developers have full access to AIX system for the asking. Back to you,
> Stefan.
That sounds great. Can we contact you directly, or have I missed an earlier
announcement from someone else giving out AIX access?
Or are you working on it
Stefan Krah added the comment:
> So, this issue with v3.10 (master) appeared to me as a regression.
I understand that from your point of view it appears as a regression.
However, quoting the C standard, 7.20.3 Memory management functions:
"The pointer returned points to the start
Stefan Krah added the comment:
Thank you, David!
Now that I can test on AIX, I can confirm that the data limit is the
culprit:
libmpdec deliberately calls malloc(52631578947368422ULL) in the
maxprec tests, which is supposed to fail, but succeeds.
However, instead of freezing the machine
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +21006
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21887
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
New changeset 40e700ad042089120456cc2ee79b8ca69479416b by Stefan Krah in branch
'master':
bpo-40878: xlc cannot handle C99 extern inline. (GH-21887)
https://github.com/python/cpython/commit/40e700ad042089120456cc2ee79b8c
Stefan Krah added the comment:
> -qmaxmem affects the compiler optimization.
I know, that's just from the Python README.AIX. I didn't expect it to have any
influence.
> -Wl,-bmaxdata:0x8 is a GCC command line option.
That is indeed surprising. Linking is prep
Stefan Krah added the comment:
To recap for people who find this: The problem occurs because of AIX's
extreme over-allocation and is specific to the 64-bit build.
Workarounds:
1) Something like ulimit -d 800.
2) xlc: LDFLAGS="-L/usr/lib64 -q64 -bmaxdata:0x8"
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +21009
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21890
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
New changeset 39dab24621122338d01c1219bb0acc46ba9c9956 by Stefan Krah in branch
'master':
bpo-41540: AIX: skip test that is flaky with a default ulimit. (#21890)
https://github.com/python/cpython/commit/39dab24621122338d01c1219bb0acc
Stefan Krah added the comment:
New changeset 1864eacc22485b26c0ec0a059c9330f877861afb by Miss Islington (bot)
in branch '3.9':
bpo-40878: xlc cannot handle C99 extern inline. (GH-21891)
https://github.com/python/cpython/commit/1864eacc22485b26c0ec0a059c9330
Stefan Krah added the comment:
New changeset 28bf82661ac9dfaf1b2d0fd0ac98fc0b31cd95bb by Miss Islington (bot)
in branch '3.9':
bpo-41540: AIX: skip test that is flaky with a default ulimit. (GH-21890)
(#21893)
https://github.com/python/cpython/commit/28bf82661ac9dfaf1b2d0fd0ac98fc
Change by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> compile error
___
Python tracker
<https://bugs.pyt
Change by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
Thanks to David Edelsohn I have AIX access now. The issue reported
by Pablo is the same as #41540, for a summary see msg375480.
It is a trivial issue that requires that ulimits are in place due to
the fact that AIX over-allocates petabytes even when the physical
Stefan Krah added the comment:
Mark, do you think that we should document the other oddity as well
or should we close this?
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issu
1101 - 1200 of 4949 matches
Mail list logo
