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
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
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
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
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
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
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
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
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 ass
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
Changes by Sergey B Kirpichev <skirpic...@gmail.com>:
--
nosy: +Sergey.Kirpichev
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
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 p
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 chang
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 us
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 de
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/issu
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
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
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.se
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/issu
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
applicat
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__
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
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 ma
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/issue44
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")`,
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/issu
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'
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 d
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 ad
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/fra
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:
>>
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
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.
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue44570>
___
___
Python-bugs-list mailing list
Unsub
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue12403>
___
___
Python-bugs-list mailing list
Unsub
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/issu
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.d
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 rea
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
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 l
Sergey B Kirpichev added the comment:
> Thank you for the suggestion
Raymond, that was Guido's suggestion.
--
___
Python tracker
<https://bugs.python.org/issu
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/issu
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
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
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 subcl
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 co
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
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 Py
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 availa
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
> ev
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-opti
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
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
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/issu
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue1814>
___
___
Python-bugs-list mailing list
Unsub
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue21922>
___
___
Python-bugs-list mailing list
Unsub
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 a
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) practi
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'
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue32891>
___
___
Python-bugs-list mailing list
Unsub
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
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
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/issu
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 dec
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,
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue23975>
___
___
Python-bugs-list mailing list
Unsub
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue23602>
___
___
Python-bugs-list mailing list
Unsub
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue11977>
___
___
Python-bugs-list mailing list
Unsub
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue30094>
___
___
Python-bugs-list mailing list
Unsub
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.
>
>
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue32133>
___
___
Python-bugs-list mailing list
Unsub
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue44626>
___
___
Python-bugs-list mailing list
Unsub
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue44840>
___
___
Python-bugs-list mailing list
Unsub
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
>
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/issu
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 Integ
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
Integr
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/issu
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
Sergey B Kirpichev added the comment:
> self(1) instead
or, rather, type(self)(1)
--
___
Python tracker
<https://bugs.python.org/issue47079>
___
___
Python-
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
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 se
83 matches
Mail list logo
