[issue47079] Integral.denominator shouldn't return an int
Sergey B Kirpichev added the comment: > It does not satisfy your assumptions in msg416056. Yes, but does it fits to assumptions of the numbers module? To be fair, there is even no requirement, that numerator/denominator are Integral instances (#25619 address also this). BTW, it seems, the numpy integer types break my guess that numerator and denominator must have same types (I doubt that anyone uses numbers.Integral defaults, there are no tests for them in the CPython itself): >>> a = numpy.int8(2); a 2 >>> type(a) >>> type(a.numerator) >>> type(a.denominator) >>> type(a + a.denominator) >>> type(a.denominator + a) >>> type(a + a) If this is an expected behaviour for Integral types - feel free to close the bugreport. Looks odd for me, however. -- ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47079] Integral.denominator shouldn't return an int
Sergey B Kirpichev added the comment: > Integral.__add__ is an abstract method, so it is a problem of your > implementation. But such an implementation does satisfy all assumptions of the Integral abc, correct? -- ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47079] Integral.denominator shouldn't return an int
Sergey B Kirpichev added the comment: > The module documentation should not contain all historical reasons of every > design decision. Sure. But, for example, there should be an explanation of why foo+foo.denominator could produce an error for a valid implementation of the Integral abc. Such interoperability is not assumed by the docs, according to provided examples (https://docs.python.org/3/library/numbers.html#implementing-the-arithmetic-operations). > One of reasons is that type(self) not always have a constructor with > compatible interface. I hardly can imagine a constructor for the Integral type, which doesn't accept a python integer as an argument. -- ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47079] Integral.denominator shouldn't return an int
Sergey B Kirpichev added the comment: > There is no "why". Why not? Apparently, this is a documentation error, at least. (And I doubt there are tests for default methods.) > If you are interesting "why", try to search old archives for the history of > creating that module. Thanks. Sorry, I'll try harder. So far I've found nothing to explain me why the Integral.denominator must be an 'int'. -- ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47079] Integral.denominator shouldn't return an int
Sergey B Kirpichev added the comment: > There is no such constrain. Why not? Any example where it does make sense to have different types for numerator and denominator? -- ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47079] Integral.denominator shouldn't return an int
Sergey B Kirpichev added the comment: > How would it work for bool or IntEnum? Neither subclass the Integral abc. The constraint (for which I care about) is: numerator/denominator should have same types. The default implementation, which I propose: it's the same type as the given Integral implementation. -- ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47079] Integral.denominator shouldn't return an int
Change by Sergey B Kirpichev : -- keywords: +patch pull_requests: +30110 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32022 ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47079] Integral.denominator shouldn't return an int
Sergey B Kirpichev added the comment: > self(1) instead or, rather, type(self)(1) -- ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47079] Integral.denominator shouldn't return an int
New submission from Sergey B Kirpichev : As the __int__() method is required, I believe it can return self(1) instead. Also, probably +self normalization could be avoided in the Integral.numerator(). -- components: Library (Lib) messages: 415660 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: Integral.denominator shouldn't return an int type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44840] Nested if/else gets phantom else trace again (3.10)
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue44840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44626] Incorrect tracing of nested if/if/for/yield
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue44626> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44570] 3.10.0b3 doesn't trace line events for return in some cases
Sergey B Kirpichev added the comment: Pablo, it seems: the 3.10 branch as for https://github.com/nedbat/coveragepy/issues/1184#issuecomment-873506523 still has this issue - I can reproduce one. -- ___ Python tracker <https://bugs.python.org/issue44570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44570] 3.10.0b3 doesn't trace line events for return in some cases
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue44570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44346] Fraction constructor may accept spaces around '/'
Sergey B Kirpichev added the comment: > See previous discussion in #9574. Given this, probably spaces around '/' should be disallowed. -- ___ Python tracker <https://bugs.python.org/issue44346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44346] Fraction constructor may accept spaces around '/'
Sergey B Kirpichev added the comment: On Wed, Jun 09, 2021 at 06:18:22AM +, Vedran Čačić wrote: > I was surprised to realize `complex` doesn't accept '2 + 3j' Good catch, probably that should be allowed too. > e.g. how about 3_j? The PEP 515 added '_' as a separator between digits. But the imaginary unit is not a digit. For same reason '1_/_2' shouldn't be allowed for the Rational constructor. (Unfortunately, the Decimal class breaks this PEP convention as well as some other, see issue44267. For example, it accepts things like '1_._2'.) -- ___ Python tracker <https://bugs.python.org/issue44346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44346] Fraction constructor may accept spaces around '/'
New submission from Sergey B Kirpichev : Per https://bugs.python.org/msg394731 suggestion. For instance, mpq_set_str() does support this. Also, gmpy2.mpq(). Tentative patch attached. -- components: Library (Lib) files: fraction-spaces.diff keywords: patch messages: 395314 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: Fraction constructor may accept spaces around '/' versions: Python 3.11 Added file: https://bugs.python.org/file50097/fraction-spaces.diff ___ Python tracker <https://bugs.python.org/issue44346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)
Sergey B Kirpichev added the comment: On Sun, May 30, 2021 at 08:58:56AM +, Mark Dickinson wrote: > Yep, you're absolutely right. I should have said "after the PEP is final" Unfortunately, neither correction can fix that the PEP does not "accurately describes the state of the implementation at the point where it is marked Final." > It would also be a backwards incompatible change at this point to > start refusing strings that were previously accepted. I'm not sure... Well, it's not so clear which strings are accepted previously (i.e. what's was documented). PEP 515 claims one. The docs says something different: >8--- If value is a string, it should conform to the decimal numeric string syntax after leading and trailing whitespace characters, as well as underscores throughout, are removed >8--- and --->8-- Underscores are allowed for grouping, _as with integral and floating-point literals in code_. -->8--- The 1-st sentence doesn't specify the way underscores are removed. And given the 2-nd sentence: it's clearly can't be like the current behaviour of the Decimal constructor. -- ___ Python tracker <https://bugs.python.org/issue44267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)
Sergey B Kirpichev added the comment: On Sun, May 30, 2021 at 08:32:40AM +, Mark Dickinson wrote: > Standards Track PEPs are historical documents; it's quite common that an > actual implementation ends up diverging from a PEP in small ways after > the PEP is accepted, and we don't usually do post-hoc updates in those > situations. Well, then I something misunderstood in PEP 0: --->8-- If changes based on implementation experience and user feedback are made to Standards track PEPs while in the Accepted or Provisional State, those changes should be noted in the PEP, such that the PEP accurately describes the state of the implementation at the point where it is marked Final. >8 I don't think that PEP describes the state of art in the decimal module. > Possibly the decimal documentation could be updated, though. The current behaviour is documented. Do you mean we should document disagreement with PEP as well? Regarding mail thread: I don't think that following the PEP will slow down string conversion. Also, probably we want that strings that supported by float() and Decimal() were interchangeable. -- ___ Python tracker <https://bugs.python.org/issue44267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)
Sergey B Kirpichev added the comment: On Sun, May 30, 2021 at 08:20:14AM +, Mark Dickinson wrote: > There was some discussion of this on the python-dev mailing list at the time I see. > It's probably best left alone. PEP 515 is clear. If this is not a bug - it should be adjusted (as it claims to cover Decimal's among other stuff). -- ___ Python tracker <https://bugs.python.org/issue44267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)
Change by Sergey B Kirpichev : Added file: https://bugs.python.org/file50072/0001-bpo-44267-fix-parsing-Decimal-s-with-underscores.patch ___ Python tracker <https://bugs.python.org/issue44267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)
New submission from Sergey B Kirpichev :
While working on issue44258 I discover that the decimal module doesn't follow
specification in PEP 515: "The current proposal is to allow one underscore
between digits, and after base specifiers in numeric literals." (c)
For example:
>>> float("1.1__1")
Traceback (most recent call last):
File "", line 1, in
ValueError: could not convert string to float: '1.1__1'
but
>>> from decimal import Decimal as C
>>> from _pydecimal import Decimal as P
>>> C("1.1__1")
Decimal('1.11')
>>> P("1.1__1")
Decimal('1.11')
Maybe this requirement could be relaxed in PEP, but it seems - this was already
discussed (see Alternative Syntax section). Hence, I think this is a bug.
Patch for _pydecimal attached.
--
components: Extension Modules, Library (Lib)
files: _pydecimal-pep515.diff
keywords: patch
messages: 394750
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Wrong PEP 515 parsing in decimal module (both C and Python versions)
versions: Python 3.11
Added file: https://bugs.python.org/file50071/_pydecimal-pep515.diff
___
Python tracker
<https://bugs.python.org/issue44267>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44258] Support PEP 515 for Fraction's initialization from string
Sergey B Kirpichev added the comment:
On Fri, May 28, 2021 at 06:48:14AM +, Mark Dickinson wrote:
> So yes please to the PR. There should be tests that check that only the
> underscore rules allowed by `int` and the others are supported: e.g.,
> `Fraction("1__2")`, and `Fraction("1_2_")` should be errors.
Ok, I did.
In the initial version I catch int()'s exceptions to
return a correct exception details. Maybe it's better to fix
the regexp instead (don't match "wrong" strings). I think
this might be more complicated for readers...
--
___
Python tracker
<https://bugs.python.org/issue44258>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44258] Support PEP 515 for Fraction's initialization from string
Change by Sergey B Kirpichev : -- pull_requests: +25017 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26422 ___ Python tracker <https://bugs.python.org/issue44258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44258] Support PEP 515 for Fraction's initialization from string
New submission from Sergey B Kirpichev :
Right now:
>>> from fractions import Fraction as F
>>> F(1_2_3, 3_2_1)
Fraction(41, 107)
but
>>> F('1_2_3/3_2_1')
Traceback (most recent call last):
File "", line 1, in
File "/home/sk/src/cpython/Lib/fractions.py", line 115, in __new__
raise ValueError('Invalid literal for Fraction: %r' %
ValueError: Invalid literal for Fraction: '1_2_3/3_2_1'
or even this (should be consistent with int constructor, isn't?):
>>> F('1_2_3')
Traceback (most recent call last):
File "", line 1, in
File "/home/sk/src/cpython/Lib/fractions.py", line 115, in __new__
raise ValueError('Invalid literal for Fraction: %r' %
ValueError: Invalid literal for Fraction: '1_2_3'
Tentative patch attached. Let me know if this does make sense as a PR.
--
components: Library (Lib)
files: fractions-from-str.diff
keywords: patch
messages: 394633
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Support PEP 515 for Fraction's initialization from string
versions: Python 3.11
Added file: https://bugs.python.org/file50069/fractions-from-str.diff
___
Python tracker
<https://bugs.python.org/issue44258>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44154] Optimize Fraction pickling
Sergey B Kirpichev added the comment:
On Thu, May 20, 2021 at 12:03:38AM +, Raymond Hettinger wrote:
> Raymond Hettinger added the comment:
> You're right that this won't work for decimal because it takes a
> string constructor. A fancier reduce might do the trick but it would
> involve modifying the C code (no fun) as well as the Python code.
Yes, it will be harder. But I think - is possible.
E.g. with this trivial patch:
$ git diff
diff --git a/Lib/_pydecimal.py b/Lib/_pydecimal.py
index ff23322ed5..473fb86770 100644
--- a/Lib/_pydecimal.py
+++ b/Lib/_pydecimal.py
@@ -627,6 +627,9 @@ def __new__(cls, value="0", context=None):
self._exp = value[2]
self._is_special = True
else:
+value = list(value)
+if isinstance(value[1], int):
+value[1] = tuple(map(int, str(value[1])))
# process and validate the digits in value[1]
digits = []
for digit in value[1]:
@@ -3731,7 +3734,7 @@ def shift(self, other, context=None):
# Support for pickling, copy, and deepcopy
def __reduce__(self):
-return (self.__class__, (str(self),))
+return (self.__class__, ((self._sign, int(self._int), self._exp),))
def __copy__(self):
if type(self) is Decimal:
Simple test suggests that 2x size difference is possible:
>>> import pickle
>>> from test.support.import_helper import import_fresh_module
>>> P = import_fresh_module('decimal', blocked=['_decimal'])
>>> P.getcontext().prec = 1000
>>> d = P.Decimal('101').exp()
>>> len(pickle.dumps(d))
1045
vs
>>> len(pickle.dumps(d))
468
with the above diff. (Some size reduction will be even if we
don't convert back and forth the self._int, due to self._exp size.
This is a less interesting case, but it's for free! No speed penalty.)
> Also, the conversion from decimal to string and back isn't quadratic,
> so we don't have the same worries.
Yes, for a speed bonus - we need to do something more clever)
> Lastly, really large fractions happen naturally as they interoperate,
> but oversized decimals are uncommon.
For financial calculations this, probably, is true. But perfectly
legal usage of this module - to compute mathematical functions with
arbitrary-precision (like mpmath does with mpmath.mpf).
Let me know if it's worth openning an issue with above improvement.
--
___
Python tracker
<https://bugs.python.org/issue44154>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: > I'll have to see if the slowdown can be mitigated somehow. Yes, for small components this is a known slowdown. I'm trying to mitigate that case in https://github.com/python/cpython/pull/25518. Except for the mixed mode (Fraction's+int) - this match the original performance. -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44154] Optimize Fraction pickling
Sergey B Kirpichev added the comment: Not sure why this wasn't closed after pr merging. If this was intentional - let me know and reopen. I'm less sure if something like this will work for a Decimal(). Perhaps, if the constructor will accept an integer as the value[1], not just a tuple of digits. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44154] Optimize Fraction pickling
Sergey B Kirpichev added the comment: > Oh yes - please do. Ok, I did. > It's not just pickle size - going through str() makes (un)pickling quadratic > time in both directions if components are large. Yeah, I noticed speedup too, but size was much more important for may application. BTW, the same issue affects some other stdlib modules, ex. in the Decimal() it will be more efficient to use the tuple (sign, digit_tuple, exponent) instead of dumping strings. Maybe more, simple fgrep suggests me also the ipaddress module, but I think here it's ok;-) -- ___ Python tracker <https://bugs.python.org/issue44154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44154] Optimize Fraction pickling
Change by Sergey B Kirpichev : -- pull_requests: +24803 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26186 ___ Python tracker <https://bugs.python.org/issue44154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44154] Optimize Fraction pickling
New submission from Sergey B Kirpichev : The current version of the Fraction.__reduce__() method uses str(), which produces bigger dumps, esp. for large components. C.f.: >>> import random, pickle >>> from fractions import Fraction as F >>> random.seed(1); a = F(*random.random().as_integer_ratio()) >>> for proto in range(pickle.HIGHEST_PROTOCOL + 1): ... print(len(pickle.dumps(a, proto))) ... 71 70 71 71 77 77 >>> b = a**13 >>> for proto in range(pickle.HIGHEST_PROTOCOL + 1): ... print(len(pickle.dumps(b, proto))) ... 444 443 444 444 453 453 vs the attached patch: >>> for proto in range(pickle.HIGHEST_PROTOCOL + 1): ... print(len(pickle.dumps(a, proto))) ... 71 68 49 49 59 59 >>> for proto in range(pickle.HIGHEST_PROTOCOL + 1): ... print(len(pickle.dumps(b, proto))) ... 444 441 204 204 214 214 Testing for non-default protocols was also added. Let me know if all this does make sense as a PR. -- components: Library (Lib) files: fractions-pickle.diff keywords: patch messages: 393781 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: Optimize Fraction pickling versions: Python 3.11 Added file: https://bugs.python.org/file50047/fractions-pickle.diff ___ Python tracker <https://bugs.python.org/issue44154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32133] documentation: numbers module nitpick
Sergey B Kirpichev added the comment: Maybe some methods from the Complex class could be moved to the Number class? I think, that something like the ring structure (probably even a commutative ring) is expected from the number classes in the Python. I.e. there should be __add__/__sub__/__mul__/__pos__/__neg__/__pow__/etc. But not __truediv__/__floordiv__. Even simpler idea: move the __eq__ method to the Number class. Then it would be impossible to instantiate a Number. -- ___ Python tracker <https://bugs.python.org/issue32133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.
Sergey B Kirpichev added the comment: On Tue, Apr 27, 2021 at 08:31:35AM +, Raymond Hettinger wrote: > Well, that complicated things ;-) I suppose he can revive this if he wants. That was just to note: it wasn't my (=> bad & stupid) idea. Lets hope, he will note, even not being subscribed :-) > Perhaps after seeing how pervasive the change is he will be less inclined. Even CPython patch is small. Downstream changes are one-line patches, much smaller than usual CPython compatibility breaks. Just to note. > Jelle, Mark, and I have all thought about it and don't think it is worth the > disruption. Agaist Guido and Terry. (I don't count Serhiy on your side.) > In 14 years we hadn't had user reports or any other evidence that word > Integral is problematic, so it isn't that there is any problem to be solved. It's not too problematic, but can surprise users. Not just me - see example with Nick in the thread. -- ___ Python tracker <https://bugs.python.org/issue32891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26092] doctest should allow custom sys.displayhook
Change by Sergey B Kirpichev : -- pull_requests: +24342 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25651 ___ Python tracker <https://bugs.python.org/issue26092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.
Sergey B Kirpichev added the comment: > Thank you for the suggestion Raymond, that was Guido's suggestion. -- ___ Python tracker <https://bugs.python.org/issue32891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.
Sergey B Kirpichev added the comment: On Tue, Apr 27, 2021 at 02:49:15AM +, Jelle Zijlstra wrote: > Forcing all of them to change doesn't seem particularly valuable. It seems, this will cost very little work on their side, much less than on the CPython side. Do you agree? Something like this change: https://docs.python.org/3.7/whatsnew/3.7.html#id3 - require much more efforts... > but "Integral" isn't actively misleading. Well, sometimes it surprise people, e.g.: https://mail.python.org/archives/list/python-id...@python.org/message/2KQSRVBUWGBVV2MPTI4J6M4BVO2NYB3V/ BTW, we already have some inconsistencies around this terminology. E.g. recently introduced Decimal.is_integer() vs to_integral(): https://bugs.python.org/issue26680#msg262715 -- ___ Python tracker <https://bugs.python.org/issue32891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.
Sergey B Kirpichev added the comment: > so I'll simply record my -1 for the proposed change and move on Mark, thank you for some PR review, anyway. I hope, we still can count Guido +1 on the change. > If you want to push this change through, the way forward would likely be to > find a core developer (maybe Terry?) who's willing to champion the change > (and review the PR, of course). I'll try. I've asked Terry for review. For the record, I've tried to find why it was decided to live with Integral class, instead of Integer. Unfortunately, it seems there was no public discussion on this. This one with Integer: https://mail.python.org/pipermail/python-3000/2007-May/007711.html and this without: https://mail.python.org/pipermail/python-3000/2007-August/009068.html -- ___ Python tracker <https://bugs.python.org/issue32891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26092] doctest should allow custom sys.displayhook
Sergey B Kirpichev added the comment: > I personally haven't encountered this problem in the past years Noam, that's because Python has your patch :-) But if we revert one - mentioned solution with mock.patch will work. Please, tell us if you find it bad for any reason. -- ___ Python tracker <https://bugs.python.org/issue26092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12403] Mention sys.displayhook in code module docs and the compile builtin docs
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue12403> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26092] doctest should allow custom sys.displayhook
Sergey B Kirpichev added the comment:
Tim, lets decide on this simple issue.
To me, https://bugs.python.org/issue8048 was obviously a bad thing. While it
"fixes" one application, which customize sys.displayhook in a strange way - it
break testing almost everyone, which do sys.displayhook customization. See
e.g. https://github.com/sympy/sympy/blob/master/conftest.py or
https://github.com/diofant/diofant/blob/master/conftest.py. BTW, SymPy is far
more popular library than dreampie, which is py2-only and looks unmaintained.
Last, but not least - introduced doctest's behaviour wasn't documented. It
break things in a surprising way and do this silently... There is a
documentation issue if you decide to keep this "feature".
Noam, what do you think about fixing your problem with mock.patch?
>>> import sys
>>> from unittest.mock import patch
>>> with patch('sys.displayhook', sys.__displayhook__):
... doctest.testmod()
Tentative patch attached.
--
keywords: +patch
Added file: https://bugs.python.org/file49985/doctest-displayhook.diff
___
Python tracker
<https://bugs.python.org/issue26092>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23975] numbers.Rational implements __float__ incorrectly
Change by Sergey B Kirpichev : -- pull_requests: +24321 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25619 ___ Python tracker <https://bugs.python.org/issue23975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.
Sergey B Kirpichev added the comment: On Fri, Apr 23, 2021 at 11:51:17AM +, Mark Dickinson wrote: > The name "Integral" isn't actually _wrong_ as such; it's just perhaps > not the name that we would have chosen if we were inventing the > numbers ABC right now. > > If we add "Integer", we have to choose between > > - maintaining both names indefinitely, or > - deprecating and eventually removing the "Integral" name > > Neither option seems appealing: the first is a violation of "one > obvious way"; the second causes unnecessary work for third-party > projects already using Integral. The second option require very small part of work (oneline patch, to be precise). The one of the best parts of the Python is that it's a live language. I.e. wrong decisions could be corrected. The current one is not wrong, in a strict sense, but if the C standard, wikipedia pages, etc (include the Scheme numbers tower) reference integer types and CPython docs call this "integral" - I'm not sure if the later is a good name. -- ___ Python tracker <https://bugs.python.org/issue32891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23975] numbers.Rational implements __float__ incorrectly
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue23975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11977] Document int.conjugate, .denominator, ...
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue11977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23602] Implement __format__ for Fraction
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue23602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30094] PDB enhancement
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue30094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32133] documentation: numbers module nitpick
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue32133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43602] Include Decimal's in numbers.Real
Sergey B Kirpichev added the comment: Well, probably everyone else agree with Raymond. Yet, I'll try to clarify few things. On Mon, Apr 19, 2021 at 03:38:29AM +, Raymond Hettinger wrote: > No strong use cases have emerged that would warrant overturning > the long-standing prior decisions on this topic. How about other multiprecision types in external libs, i.e. mpmath.mpf or gmpy2.mpfr? Probably, these shouldn't be Real's as well, isn't? In this way, the whole numbers tower above Rational class is more or less useless, as mentioned by Oscar: Real ABC is essentially reduced to float and Complex ABC - to complex... Raymond, I won't object your current decision for Decimal. But do you think - there is no documentation issues with the numbers module, related to Real/Complex? The module doesn't document, for example, that R1 + R2 is expected to work if R1 and R2 are both Reals (but different implementations). I'm not sure if this is a sane design decision (as this will restrict Real ABC just to float's), but if so - it must be documented. (comments are internal documentation, isn't?). It's not obvious. (The proof e.g. is that Decimal vs Real issue was questioned several times by different people.) -- ___ Python tracker <https://bugs.python.org/issue43602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.
Change by Sergey B Kirpichev : -- keywords: +patch pull_requests: +24272 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/25552 ___ Python tracker <https://bugs.python.org/issue32891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27763] Add complex case to test_builtin abs()
Sergey B Kirpichev added the comment: > We're testing the cmath functions on complex number inputs Indeed. Also, for abs(complex) - there is test_abs() in the test_complex.py. > The complex number creation from both strings and pairs of floats should be > tested independently, of course. It seems, there are such tests as well. E.g. test_constructor() in the same file. Mark, perhaps this can be closed? -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue27763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43602] Include Decimal's in numbers.Real
Sergey B Kirpichev added the comment: Probably, this thread https://mail.python.org/archives/list/python-id...@python.org/thread/KOE3MQ5NSMGTLIH6IHAQWTIOELXG4AFQ/ is relevant here. I would appreciate Oscar's feedback on this issue. -- nosy: +oscarbenjamin ___ Python tracker <https://bugs.python.org/issue43602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue32891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32466] Fix missing test coverage for fractions.Fraction.__new__
Sergey B Kirpichev added the comment: Mark, I think the Lib/fractions.py now is covered by tests in the test_fractions.py. $ ./python -m venv ~/venv/cpython $ . ~/venv/cpython/bin/activate $ pip install coverage Collecting coverage Using cached coverage-5.5-cp310-cp310-manylinux1_x86_64.whl (238 kB) Installing collected packages: coverage Successfully installed coverage-5.5 $ python -m coverage run --source=fractions --branch Lib/test/test_fractions.py ... -- Ran 31 tests in 0.040s OK $ ~/venv/cpython/bin/python -m coverage report Name Stmts Miss Branch BrPart Cover Lib/fractions.py 299 0126 0 100% TOTAL299 0126 0 100% My guess: this issue can be closed. -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue32466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43602] Include Decimal's in numbers.Real
Sergey B Kirpichev added the comment:
On Tue, Mar 23, 2021 at 01:03:47PM +, Mark Dickinson wrote:
> What do you think the result of `1.0 + Decimal(1)` should be, and
> more importantly why? Possible options are:
>
> - Decimal('2')
> - 2.0 (a float)
> - a `TypeError` (as now)
> - some kind of horrible user-configurable-global-state-dependent answer
Decimal, with a some kind of "horrible
user-configurable-global-state-dependent answer" (Decimal
context): reverse conversion might be inexact.
Same, in principle, holds for 2-base multiprecision arithmetic
types like gmpy2.mpfr and mpmath.mpf. "More powerfull data type,
claiming it implements numbers.Real - should know better."
That's the first option.
Maybe I (and authors of mentioned above packages) - do miss something
important. (Oh, count on SageMath too.)
But do we have other examples of numbers.Real implementations (or
claiming to be such)? If the numbers.Real does mean something like "only
python's builtin floats, but maybe with a different multiplication
algorithm" - that's hardly something that people may expect from
the docs. Real numbers have a very specific mathematical meaning and
things like mpmath's mpf or Decimal fit this.
> Bear in mind that you have to pick a behaviour that's a good default
> choice for all potential application domains, and that's *hard*.
I think, that TypeError (a second option) might make sense too. I'm not
sure that different implementations of numbers.Real must be interoperable (i.e.
without explicit conversions). Such requirement clearly does make sense for
exact data types in the numerical tower (i.e. different
numbers.Rational implementations).
So, this implementation of the numbers tower:
int (Integral) - Fraction (Rational) - float (Real) - complex (Complex)
doesn't look "more correct", than this:
gmpy2.mpz - gmpy2.mpq - gmpy2.mpfr - gmpy2.mpc
regardless on how do "inexact" data types (e.g. float vs mpfr)
interoperate. Same may be for the Decimal (but this is not a full tower):
int - Fraction - Decimal.
--
___
Python tracker
<https://bugs.python.org/issue43602>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43602] Include Decimal's in numbers.Real
Sergey B Kirpichev added the comment:
On Tue, Mar 23, 2021 at 10:21:50AM +, Mark Dickinson wrote:
> Mark Dickinson added the comment:
> > I assume, the reason is: there is no lossless conversion to float's (and
> > vice verse).
> and in fact we _do_ have lossless conversion of floats to Decimal instances
Indeed, context precision doesn't affect this. (But still, reversed
conversion is inexact in general).
> - it's not obvious what the *type* of the result of some_float +
> some_other_decimal should be
Seems so, for a static typing. But Python is a dynamically typed
language, isn't?
>>> import gmpy2
>>> gmpy2.mpfr('1.0') + 1.0
mpfr('2.0')
>>> 1.0 + gmpy2.mpfr('1.0')
mpfr('2.0')
(ditto mpmath)
> - it seems rather likely that any attempt to combine a float and
> a Decimal instance in this way is a bug, or at least something that
> hasn't been fully thought through by the developer, so we
> force the developer to make an explicit conversion
Maybe it's ok for base-2 multiprecision arithmetics, as in the
example above.
Maybe not. But in this case, if interoperability with float's (or any other
implementation for numbers.Real) is a requirement for any
numbers.Real-derived class - that should be documented. Perhaps, then
there are bugs in mpmath/gmp2, which do claim they implement Real type:
i.e. either they should't implement automatic conversion or don't claim
they do implement numbers.Real.
> For historical discussions, see #1682.
Thank you, I'll look into.
--
___
Python tracker
<https://bugs.python.org/issue43602>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43602] Include Decimal's in numbers.Real
Sergey B Kirpichev added the comment: > Operations between decimals and floats raise a TypeError. I saw this) And as I said, I assume, the reason is: there is no lossless conversion to float's (and vice verse). If so (point 2), neither multiple-precision type (e.g. gmpy2.mpfr) can subclass from the numbers.Real (there can be different precisions, different bases) and that sounds too restrictive. >From the mathematician point of view, both built-in float's and Decimal's >could be viewed as (inexact!) representations for real numbers. But if _any_ >such representations, conforming the numbers abc must be lossless converted to >each other - that might be a documentation issue. > P.S. With respect to #4, we've harmonized the APIs as much as we sensibly > can. That was very minor, yes. Something like try-except could be used here, trying as_integer_ratio(). -- ___ Python tracker <https://bugs.python.org/issue43602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43602] Include Decimal's in numbers.Real
New submission from Sergey B Kirpichev : Commit 82417ca9b2 includes Decimal's in the numbers tower, but only as an implementation of the abstract numbers.Number. The mentioned reason is "Decimals are not interoperable with floats" (see comments in the numbers.py as well), i.e. there is no lossless conversion (in general, in both directions). While this seems to be reasonable, there are arguments against: 1) The numbers module docs doesn't assert there should be a lossless conversion for implementations of same abstract type. (Perhaps, it should.) This obviously may be assumed for cases, where does exist an exact representation (integers, rationals and so on) - but not for real numbers (or complex), where representations are inexact (unless we consider some subsets of real numbers, e.g. some real finite extension of rationals - I doubt such class can represent numbers.Real). (Unfortunately, the Scheme distinction of exact/inexact was lost in PEP 3141.) 2) By same reason, I think, neither binary-based multiprecision arithmetics package can represent numbers.Real: i.e. gmpy2.mpfr, mpmath.mpf and so on. (In general, there is no lossless conversion float's, in both directions.) 3) That might confuse users (why 10-th base arbitrary precision floating point arithmetic can't represent real numbers?). 4) Last, but not least, even some parts of stdlib uses both types in an interoperable way, e.g. Fraction constructor: elif isinstance(numerator, (float, Decimal)): # Exact conversion self._numerator, self._denominator = numerator.as_integer_ratio() return self -- assignee: docs@python components: Documentation, Library (Lib) messages: 389372 nosy: Sergey.Kirpichev, docs@python priority: normal severity: normal status: open title: Include Decimal's in numbers.Real versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: On Mon, Mar 22, 2021 at 04:34:32AM +, Tim Peters wrote: > For example, setting up a module global `_gcd` name for `math.gcd` Looking on the stdlib, I would just import gcd. > default `_gcd=math.gcd` arguments to the methods? Then it's > even faster (& uglier, of course). ... and less readable. Not sure if speedup will be noticeable. But more important is that I see no such micro-optimizations across the stdlib. Probably, this will be the reason for rejection. > Or wrt changing properties to private attributes, that speeds some > things but slows others - and, unless I missed it, nobody who wrote > that code to begin with said a word about why it was done that way. Yes, I'll dig into the history. Commen^WDocstring doesn't explain this (for me). > Opening a BPO report is a trivial effort. Sure, but such report will require patch to be discussed, anyway. -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: On Mon, Mar 22, 2021 at 02:35:59AM +, Tim Peters wrote: > Thanks, all! This has been merged now. If someone wants to > continue pursuing things left hanging, I'd suggest opening > a different BPO report. Tim, if you are about micro-optimizations for small components (properties->attributes and so on, I think this not worth BPO report of the news entry, isn't? Thanks for all reviewers and commenters. -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: > a short paragraph or section on alternative implementations There are no alternative implementations. SymPy's PythonRational (AFAIR, this class not in the default namespace) is an internal fallback solution, for case when no gmpy2 is available. Maybe we should list gmpy2 everywhere people expect fast bigint/rationals (i.e. int docs, math module, Fraction and so on), so they will not not be disappointed... > complexity (and assured correctness) Much more complex (IMHO) code was accepted (there were examples for C, but the limit_denominator() method - an example for Python code, from the same module!). In fact, it pretty obvious that output fractions are equal to the middle-school versions. Non-trivial part may be why they are normalized. I hope, now this covered by comments. -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: On Tue, Mar 09, 2021 at 05:11:09AM +, Tim Peters wrote: > those for + and - are much subtler In fact, these optimizations will payoff faster (wrt denominators size), esp. due to gcd==1 branch. Sorry for off-topic: > WRT which, I added Python's Karatsuba implementation and regret doing so. > I don't want to take it out now (it's already in ;-) ), but it added quite > a pile of delicate code to what _was_ a much easier module to grasp. (And was much more useless, even as a fallback. But in the end - I agreed, you can't outperform professional bigint implementations. I think, you can _use_ them instead.) > People who need fast multiplication are still far better off using gmpy2 > anyway (Another strange python "feature", IMHO. Why the custom bigint implementation, why not use the project, that run professionals in the field? Looking on the issue 21922 - it seems, that small ints arithmetics can be almost as fast as for python ints. Is the memory handling - out-of-memory situation - the only severe problem?) -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: On Sun, Mar 07, 2021 at 12:16:36PM +, Mark Dickinson wrote: > but not the "incompatible denominators" part. :-) The typical use there is > that those fractions have been converted from floats But there is no limits to use Fraction's for input, e.g. there are docstring examples for mean() and variance(). In that case (general one for a summation) - common denominators is a very special situation. > Thanks for the timings! So assuming that wasn't a specially-chosen best case > example No, but this will handle the first branch. > > It's not going to be complicated so much > For me, the big difference is that the current code is obviously correct That may be fixed by keeping relevant references right in the code, not in the commit message. Python sources have many much more non-trivial algorithms... -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: On Sun, Mar 07, 2021 at 10:34:24PM +, Aaron Meurer wrote: > I'm surprised to hear that the "typical use-case" of Fraction > is fractions converted from floats. For statistics module - that may be true. Unfortunately, no (other) practical applications, using Fraction's, were proposed by my reviewers so far. > By the way, the "algorithm" here really isn't that > complicated. I didn't even realize it had a name. Rather "algorithms"; everything is there in the II-nd volume of the Knuth, section 4.5 - Rational Arithmetic. Probably, this is even a better reference, since it explains gcd==1 case for addition. Both, however, reference the Henrici article. > It's far less complicated than, for example, Lehmer's gcd > algorithm (which is implemented in math.gcd). Or Karatsuba multiplication. BTW, low-denominators performance may be restored (at least partially), using same approach (like KARATSUBA_CUTOFF - but checking the maximal denominator). I don't like this idea, but... -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: > I'd prefer to keep the code simplicity It's not going to be complicated so much and algorithms are well known, but I see your point. > and the speed for small inputs here Speed loss is not so big, 10-20%. > Python's needs aren't the same as SymPy's needs or SAGE's needs So, for which needs it will serve? Sorry, I can't suggest an application, which does use builtin Fraction's (not sure if even SAGE uses them, as a fallback). SymPy doesn't, for sure (but it could - it's PythonRational class uses same optimizations, except for g == 1 branches in _add/_sub, I think). There is one exception I've found: stdlib's statistics module uses Fraction's in the _sum() helper, exactly in a paradigm "sum a lot of values". > not all of the fractions.Fraction use-cases involve summing lots of values > with incompatible denominators. No need for a lots of values (i.e. 1000): denominator of the sum will grow very fast, that why modern CAS use modular GCD algorithms, for example. > Could you give some idea of the crossover point for a single addition? $ ./python -m timeit -r11 -s 'from fractions import Fraction as F' -s 'a=F(10,31011021112)' -s 'b=F(86,11011021115)' 'a + b' 2 loops, best of 11: 12.4 usec per loop $ ./python -m timeit -r11 -s 'from patched import Fraction as F' -s 'a=F(10,31011021112)' -s 'b=F(86,11011021115)' 'a + b' 2 loops, best of 11: 12.5 usec per loop -- ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1814] Victor Stinner's GMP patch for longs
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue1814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21922] PyLong: use GMP
Change by Sergey B Kirpichev : -- nosy: +Sergey.Kirpichev ___ Python tracker <https://bugs.python.org/issue21922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Change by Sergey B Kirpichev : -- pull_requests: +23544 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24779 ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
Sergey B Kirpichev added the comment: I have similar timings (for a draft version of PR, see f.patch) as for the last comment, though the small-dens overhead seems to be bigger(~20%): $ python3.10 -m timeit -r11 -s 'from fractions import Fraction as F' -s 'a=F(10,3)' -s 'b=F(6, 5)' 'a * b' 5 loops, best of 11: 9.09 usec per loop $ python3.10 -m timeit -r11 -s 'from patched import Fraction as F' -s 'a=F(10,3)' -s 'b=F(6, 5)' 'a * b' 2 loops, best of 11: 11.2 usec per loop On another hand, here are timings for bigger denominators: $ python3.10 -m timeit -r11 -s 'from fractions import Fraction as F' -s 'import random' -s 'n = [random.randint(1, 100) for _ in range(1000)]' -s 'd = [random.randint(1, 100) for _ in range(1000)]' -s 'a=list(map(lambda x: F(*x), zip(n, d)))' 'sum(a)' 1 loop, best of 11: 257 msec per loop $ ... from patched ... 10 loops, best of 11: 33.2 msec per loop It's not so clear what "are very large" does mean, that could be defined here. BTW, 10**6 denominators are (very!) small for mentioned above use case (CAS package). -- keywords: +patch Added file: https://bugs.python.org/file49854/f.patch ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43420] Optimize rational arithmetics
New submission from Sergey B Kirpichev : fractions.py uses naive algorithms for doing arithmetics. It may worth implementing less trivial versions for addtion/substraction and multiplication (e.g. Henrici algorithm and so on), described here: https://www.eecis.udel.edu/~saunders/courses/822/98f/collins-notes/rnarith.ps as e.g gmplib does: https://gmplib.org/repo/gmp/file/tip/mpq/aors.c Some projects (e.g. SymPy here: https://github.com/sympy/sympy/pull/12656) reinvent the stdlib's Fraction just to add such simple improvements. With big denominators (~10**6) this really does matter, my local benchmarks suggest the order of magnitude difference for summation of several such numbers. -- components: Library (Lib) messages: 388200 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: Optimize rational arithmetics type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32832] doctest should support custom ps1/ps2 prompts
Sergey B Kirpichev added the comment: > They support _more than one_ set of PS1/PS2 conventions. I saw this, not sure if that's required. IMHO, same effect should be possible by running doctest several times with different conventions. > Who would it help? In principle, any project, that uses some custom shell (i.e. IPython) per default. I believe, "easily understood tests" should start with prompts that users could easily recognise. > Something that might change my mind: find an author of a widely used > alternative Python shell who says this change would allow them to _remove_ > their own doctest-PS1/PS2 customization code. That would be a real use case. I admit, exactly this use case I can't provide right now. -- ___ Python tracker <https://bugs.python.org/issue32832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32832] doctest should support custom ps1/ps2 prompts
Sergey B Kirpichev <skirpic...@gmail.com> added the comment: > are people writing an entirely different shell interface. They're rare. Or just using a different shell interface. Or even different defaults for the standard shell... And they are not rare. Almost nobody in reality use CPython shell - that's definitely true for scientific applications of Python, data scientists, etc. > As your IPython example showed, their job is harder than _just_ replacing > PS1/PS2. Yes, custom shells have much more stuff (In/Out arrays, etc), but changing PS1/PS2 - require very tiny modifications for doctest. And such changes - almost all that usually prevent using standard doctest for testing examples, written for applications, which assume "a different shell interface" (which, I remind, may be just a plain CPython shell with customized ps1/ps2). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32832] doctest should support custom ps1/ps2 prompts
Sergey B Kirpichev <skirpic...@gmail.com> added the comment: > doctest was intended to deal with the standard CPython terminal shell. I'd > like to keep it that way The point is: ps1/ps2 customization could be considered as part of the standard shell. If stdlib allow such changes - doctest module should take this into account. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32832] doctest should support custom ps1/ps2 prompts
New submission from Sergey B Kirpichev <skirpic...@gmail.com>: The Python stdlib allows override of sys.ps1/ps2 (to make IPython-like dynamic prompts and so on). I believe it would be a good idea to support this in doctest too, to cover cases when given application uses different from defaults settings for the interpreter. Probably, we could add ps1/2 optional arguments for DoctestParser.__init__(). Some projects already patch doctest module for this, e.g. IPython: https://github.com/ipython/ipython/blob/master/IPython/testing/plugin/ipdoctest.py It shouldn't be too hard to port this feature. -- components: Library (Lib) messages: 312053 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: doctest should support custom ps1/ps2 prompts ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Add mechanism to disable optimizations
Changes by Sergey B Kirpichev <skirpic...@gmail.com>: -- nosy: +Sergey.Kirpichev ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue2506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28354] DeprecationWarning not reported for invalid escape sequences
New submission from Sergey B Kirpichev:
We know from release notes, that "A backslash-character pair that is not a
valid escape sequence now generates a DeprecationWarning". Sometimes it's true:
$ python -W error
Python 3.6.0b1+ (default, Oct 4 2016, 08:47:51)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> "xxx" != "hello \world"
DeprecationWarning: invalid escape sequence '\w'
But shouldn't DeprecationWarning be in the following case as well?
$ cat a.py
def f(s):
return s != "hello \world"
$ cat b.py
import a
print(a.f("xxx"))
$ python b.py
True
$ python -W error b.py
True
--
components: Interpreter Core
messages: 278020
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: DeprecationWarning not reported for invalid escape sequences
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28354>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26092] doctest should allow custom sys.displayhook
Sergey B Kirpichev added the comment: > What problem does replacing __displayhook__ provoke? I don't know for sure. But the documentation says "These objects contain the original values of displayhook and excepthook at the start of the program." So, other code in stdlib may assume something about __displayhook__ value. I.e. it writes the values it gets to sys.stdout. (Apparently, doctest thinks so.) Such assumptions should be documented, before people can override __displayhook__ safely. > What solution do you propose instead of 8048, which fixed a bug? IMHO, it's not a bug. Why not override sys.displayhook just for doctests in this application? PS: Sorry for late answer, somehow I haven't got mail notification after your reply. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26092] doctest should allow custom sys.displayhook
New submission from Sergey B Kirpichev: The purpose of doctest's - verify interactive examples. But if your users will use custom displayhook all the time (consider, as examples CAS like SymPy or https://github.com/skirpichev/omg/) - why you must show them examples with the builtin's displayhook? After https://bugs.python.org/issue8048, sys.displayhook can't be customized for doctest. I think, that decision was wrong and we should have a better solution. PS: In fact, right now this issue can be workarrounded if you instead override sys.__displayhook__ before doctest call. But I believe this "solution" has own problems. -- components: Library (Lib) messages: 258115 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: doctest should allow custom sys.displayhook type: behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 03:25:19PM +, Benjamin Peterson wrote: So, basically you need a base case for recursion? What's wrong with explicitly writing that out? Because it's complex (and costly). This is not a trivial test and I don't see reasons to fix that is not broken. And it will be difficult to explain for readers: remember, I need this exceptional case only in the world with a strange Python's convention (Python try to sort a list when it doesn't make sense). Mathematical algorithm is not broken - programming language is. Here is C: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/msort.c;#l45 Here is Ruby: https://github.com/ruby/ruby/blob/trunk/array.c#L2454 It's practical if you have a broken key function and test it with a one element list. It's silly to test key function on a single-element list *only*. BTW, why this issue was closed? 3 of us agreed this doesn't seem like a suitable change. And 1 seems to be ok with patch. Is this just a question of number of votes? At least, please consider this as a documentation issue. That ... feature may be obvious for a Python developer, but not for mathematician (as well as ordinary Python user). When key function value has no sense at all - it's not clear from the documentation, that the key function will be called. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 05:44:22PM +, Paul Moore wrote: I think the documentation is fine: The key corresponding to each item in the list is calculated once and then used for the entire sorting process. Does any sorting process make sense for [1] or []?! No, it isn't. So, it's not clear if this process started at all. This not just mine opinion - most computer languages implement the quick exit in question (see examples above). It's a common computer science technique Could you provide any language that avoid this optimization? Here is Perl 5: http://perl5.git.perl.org/perl.git/blob/HEAD:/pp_sort.c#l367 (third example) Your existing code, with a check for Omega having length 1 and omitting the sort in that case, looks entirely reasonable to me. (Well, then I should look for other languages, if Python devs insist in doing useless work...) Maybe you could add a comment Avoid a costly calculation of the key when length is 1, as we know we don't need to sort then I sure, for most people - the idea of sorting list with one element will look crazy. There is no room for any costly calculations. (Common sense, nothing more.) So, such comment will add more questions... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Changes by Sergey B Kirpichev skirpic...@gmail.com: Added file: http://bugs.python.org/file39232/0001-list.sort-Add-quick-exit-if-length-of-list-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 06:51:21PM +, Paul Moore wrote: But that's a sort without a key. Why it does matter? It have quick exit. For same reasons - Python could... In Perl you do a key sort via: That's just your implementation. But we could add here a quick exit as well. The fact of the matter is that what Python does is documented behaviour No. Unless you absolutely sure - all readers think that sorting process starts even for trivial lists. No reasons to believe in that nonsense - as you could see from sorting implementations in other languages. benefit (small) isn't worth the cost of making a change (which would only be in Python 3.5 and later anyway It's easy for users (i.e. me) to backport this feature (i.e. make wrapper for sorted()). Benefit is small, I admit, but why not remove unnecessary restrictions from the language? I hope, I did my best to explain why. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
New submission from Sergey B Kirpichev: If there is nothing to sort (i.e. one item), why call key function at all? In my practical situation, simplest key() function will lead to recursion in case of such trivial lists. I can make similar cmp-type function (i.e. mycmp=lambda a, b: cmp(key(a), key(b))) and then wrap this with cmp_to_key. But that looks silly. Simple test case: $ cat a.py a = [1] def spam(x): raise Exception a.sort(key=spam) print(a) $ python a.py Traceback (most recent call last): File a.py, line 6, in module a.sort(key=spam) File a.py, line 4, in spam raise Exception Exception -- components: Interpreter Core files: trivial-sorting-py3.patch keywords: patch messages: 24 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: list.sort() should do quick exit if len(list) = 1 type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39231/trivial-sorting-py3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Sergey B Kirpichev added the comment: should I add a regression test? If so, where? ./Lib/test/test_sort.py? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 02:32:34PM +, Benjamin Peterson wrote: Why does your key function depend on the size of the list? Because it's a real life. Here is the code: https://github.com/skirpichev/omg/blob/gruntz-use-subs/sympy/series/gruntz.py#L337 Algorithm is recursive and computation of MRV set will be finished only if I add an exceptional case for len(Omega). Or even more ugly solution with cmp-style function: https://github.com/skirpichev/omg/blob/efc70377639f78fc0f246629989056cb80a71923/sympy/series/gruntz.py#L339 Considering calling the key function is observable behavior, I don't think this should be changed. The patch makes behavior list.sort() inconsistent. Yes, in some sense. On another hand, it's reasonable to believe that key function will be called iff we need one. But if there is nothing to sort at all - why do sorting, why you want to call key function? Looks irrational to me. Last by not least. Why the return value of the key function *must* be defined in this case? Just a hidden, undocumented restriction and has no practical value. BTW, why this issue was closed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
