New submission from Sergey Fedorov :
While adding definitions for additional universal binary option (ppc+ppc64) is
rather straightforward (following already existing examples in the source
code), and Python 3.x after patching do build as universal for named two arch,
trying to install any
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,
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:
> 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
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
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
Sergey B Kirpichev added the comment:
> self(1) instead
or, rather, type(self)(1)
--
___
Python tracker
<https://bugs.python.org/issue47079>
___
___
Python-
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
New submission from Sergey M. :
Due to
```python
try:
self.handle()
finally:
self.finish()
```
construct in `socketserver.BaseRequestHandler.__init__()` method inherited
classes with `overrided __init__()` method may suffer from incomplete
initialization.
For example, in the
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue44840>
___
___
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
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 Fedoseev :
--
nosy: +sir-sigurd
nosy_count: 8.0 -> 9.0
pull_requests: +25593
pull_request: https://github.com/python/cpython/pull/27033
___
Python tracker
<https://bugs.python.org/issu
Change by Sergey Fedoseev :
--
nosy: +sir-sigurd
___
Python tracker
<https://bugs.python.org/issue39759>
___
___
Python-bugs-list mailing list
Unsubscribe:
Sergey B Kirpichev added the comment:
> See previous discussion in #9574.
Given this, probably spaces around '/' should be disallowed.
--
___
Python tracker
<https://bugs.pytho
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
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 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 des
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
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 adju
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
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:
&g
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
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/cpyth
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
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
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
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
app
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
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
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 Maslyakov added the comment:
Thank you, Dennis! I was wrong. Closing the ticket.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Sergey Maslyakov :
https://docs.python.org/3/library/subprocess.html#subprocess.check_output
The code sample seems to have a misplaced closing round bracket. It should go
after "stdout"
```
run(..., check=True, stdout=PIPE).stdout
```
--
assignee: d
Change by Sergey Polischouck :
--
nosy: +polischouckserg
___
Python tracker
<https://bugs.python.org/issue15907>
___
___
Python-bugs-list mailing list
Unsub
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,
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:
> Thank you for the suggestion
Raymond, that was Guido's suggestion.
--
___
Python tracker
<https://bugs.python.org
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?
Someth
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 t
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 f
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue12403>
___
___
Python-bugs-list mailing list
Unsub
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
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:
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/issue23975>
___
___
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/issue23602>
___
___
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
Change by Sergey B Kirpichev :
--
nosy: +Sergey.Kirpichev
___
Python tracker
<https://bugs.python.org/issue32133>
___
___
Python-bugs-list mailing list
Unsub
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 prio
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:
> 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 independen
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: +oscarben
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:
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
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 `TypeE
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
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
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
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
&g
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-opt
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 a
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:
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&
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) p
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 ar
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
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
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)' -
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 Nudnou added the comment:
Hello,
I've just run into a related issue. I have a python script, which starts an
another python script using subprocess.Popen(). The parent script gets pid of
the child and monitors up its activity through a database by this pid. The
child script up
Change by Sergey Fedoseev :
--
nosy: +sir-sigurd
nosy_count: 4.0 -> 5.0
pull_requests: +21279
pull_request: https://github.com/python/cpython/pull/21763
___
Python tracker
<https://bugs.python.org/issu
Change by Sergey Fedoseev :
--
nosy: +sir-sigurd
___
Python tracker
<https://bugs.python.org/issue35276>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Sergey Fedoseev :
--
nosy: +sir-sigurd
___
Python tracker
<https://bugs.python.org/issue26834>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Sergey Fedoseev :
--
keywords: +patch
pull_requests: +20793
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21652
___
Python tracker
<https://bugs.python.org/issu
New submission from Sergey Fedoseev :
In [191]: import dataclasses, pydoc
In [192]: @dataclass
...: class C:
...: pass
...:
In [193]: print(pydoc.render_doc(C))
Python Library Documentation: class C in module __main__
class C(builtins.object)
| C() -> None
|
|
Change by Sergey Fedoseev :
--
keywords: +patch
pull_requests: +20336
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21179
___
Python tracker
<https://bugs.python.org/issu
New submission from Sergey Fedoseev :
Currently patlib.Path.iterdir() filters out '.' and '..'.
It's unneeded since patlib.Path.iterdir() uses os.listdir() under the hood,
which returns neither '.' nor '..'.
https://docs.python.org/3/library/os.ht
Change by Sergey Fedoseev :
--
nosy: +sir-sigurd
nosy_count: 3.0 -> 4.0
pull_requests: +19338
pull_request: https://github.com/python/cpython/pull/15659
___
Python tracker
<https://bugs.python.org/issu
Change by Sergey Fedoseev :
--
pull_requests: +17021
pull_request: https://github.com/python/cpython/pull/17539
___
Python tracker
<https://bugs.python.org/issue27
Change by Sergey Fedoseev :
--
pull_requests: +16894
pull_request: https://github.com/python/cpython/pull/17413
___
Python tracker
<https://bugs.python.org/issue37
Change by Sergey Fedoseev :
--
nosy: +sir-sigurd
___
Python tracker
<https://bugs.python.org/issue38524>
___
___
Python-bugs-list mailing list
Unsubscribe:
Sergey Fedoseev added the comment:
issue38524 is related.
--
nosy: +sir-sigurd
___
Python tracker
<https://bugs.python.org/issue38517>
___
___
Python-bugs-list m
Sergey Fedoseev added the comment:
These warnings are caused by
https://github.com/python/cpython/commit/c6734ee7c55add5fdc2c821729ed5f67e237a096.
I'd fix them, but I'm not sure if we are going to restore CHECK_SMALL_INT()
¯\_(ツ)_/¯
--
nosy: +
Sergey Fedoseev added the comment:
> If you care of _PyLong_Copy() performance, you should somehow manually inline
> _PyLong_New() inside _PyLong_Copy().
It doesn't solve this:
> We could add a function that bypass that check, but in LTO build
> PyObject_MALLOC(
Sergey Fedoseev added the comment:
FWIW I proposed to add Py_ASSUME() macro that uses __builtin_unreachable() in
bpo-38147.
--
___
Python tracker
<https://bugs.python.org/issue38
Change by Sergey Fedoseev :
--
keywords: +patch
pull_requests: +15852
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16257
___
Python tracker
<https://bugs.python.org/issu
New submission from Sergey Fedoseev :
I wrote patch that cleans up type_init():
1. Removes conditions already checked by assert()
2. Removes object_init() call that effectively creates an empty tuple and
checks that this tuple is empty
--
messages: 352710
nosy: sir-sigurd
priority
Sergey Fedoseev added the comment:
Also quote from Py_UNREACHABLE() doc:
> Use this in places where you might be tempted to put an assert(0) or abort()
> call.
https://github.com/python/cpython/commit/6b519985d23bd0f0bd072b5d5d5f2c60a81a19f2
does exactly that, it replaces assert(0
Sergey Fedoseev added the comment:
I believe that the problem is caused by the change in Py_UNREACHABLE()
(https://github.com/python/cpython/commit/3ab61473ba7f3dca32d779ec2766a4faa0657923).
Before the mentioned commit Py_UNREACHABLE() was an expression, now it's a
block. Py_UNREAC
New submission from Sergey Fedoseev :
GCC (along with Clang and ICC) has __builtin_unreachable() and MSVC has
__assume() builtins, that can be used to optimize out unreachable conditions.
So we could add macro like this:
#ifdef Py_DEBUG
# define Py_ASSUME(cond) (assert(cond))
#else
# if
Change by Sergey Fedoseev :
--
keywords: +patch
pull_requests: +15517
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15274
___
Python tracker
<https://bugs.python.org/issu
Change by Sergey Fedoseev :
--
keywords: +patch
pull_requests: +15471
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14838
___
Python tracker
<https://bugs.python.org/issu
Sergey Fedoseev added the comment:
I use GCC 9.2.
--
___
Python tracker
<https://bugs.python.org/issue38015>
___
___
Python-bugs-list mailing list
Unsubscribe:
Sergey Fedoseev added the comment:
I added similar patch that replaces get_small_int() with macro version, since
it also induces unnecessary casts and makes machine code less efficient.
Example assembly can be checked at https://godbolt.org/z/1SjG3E.
This change produces tiny, but
1 - 100 of 298 matches
Mail list logo
