[issue39096] "Format Specification Mini-Language" doc mistake for Decimal

2020-11-30 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Should this issue be closed, or are you thinking of more changes?

I've made one more round of changes in GH-23575. Once that's gone in, I think 
we can close this issue.

I don't think we're ever going to be able to make this table perfectly 
accurate; at best, we can achieve a series of successive approximations to the 
truth. (Which is pretty much what I aim for when teaching.)

--

___
Python tracker 
<https://bugs.python.org/issue39096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39096] "Format Specification Mini-Language" doc mistake for Decimal

2020-11-30 Thread Mark Dickinson


Change by Mark Dickinson :


--
pull_requests: +22455
pull_request: https://github.com/python/cpython/pull/23575

___
Python tracker 
<https://bugs.python.org/issue39096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39096] "Format Specification Mini-Language" doc mistake for Decimal

2020-11-29 Thread Mark Dickinson


Mark Dickinson  added the comment:

The 'default precision' issue is addressed; the issues that Michael reported 
about the `None` presentation type are still valid, I think.

--

___
Python tracker 
<https://bugs.python.org/issue39096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39096] "Format Specification Mini-Language" doc mistake for Decimal

2020-11-29 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset c3009a5818112b5fb8867d786ce33e0e9489f4e0 by Miss Islington (bot) 
in branch '3.8':
bpo-39096: Improve description of 'e', 'f' and 'g' presentation types 
(GH-23537) (GH-23551)
https://github.com/python/cpython/commit/c3009a5818112b5fb8867d786ce33e0e9489f4e0


--

___
Python tracker 
<https://bugs.python.org/issue39096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39096] "Format Specification Mini-Language" doc mistake for Decimal

2020-11-29 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset cf47b3969e21f66655fcb414ff9bfdd503069c2d by Miss Islington (bot) 
in branch '3.9':
bpo-39096: Improve description of 'e', 'f' and 'g' presentation types 
(GH-23537) (GH-23550)
https://github.com/python/cpython/commit/cf47b3969e21f66655fcb414ff9bfdd503069c2d


--

___
Python tracker 
<https://bugs.python.org/issue39096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42496] Don't change indentation of RST markup

2020-11-29 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue42496>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39096] "Format Specification Mini-Language" doc mistake for Decimal

2020-11-29 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset c642374b3ef72f6f300616f07aea2a3f9ed83e51 by Mark Dickinson in 
branch 'master':
bpo-39096: Improve description of 'e', 'f' and 'g' presentation types (#23537)
https://github.com/python/cpython/commit/c642374b3ef72f6f300616f07aea2a3f9ed83e51


--

___
Python tracker 
<https://bugs.python.org/issue39096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39096] "Format Specification Mini-Language" doc mistake for Decimal

2020-11-28 Thread Mark Dickinson


Change by Mark Dickinson :


--
keywords: +patch
pull_requests: +22419
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23537

___
Python tracker 
<https://bugs.python.org/issue39096>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42467] slice().indices() returns incorrect values

2020-11-25 Thread Mark Dickinson


Mark Dickinson  added the comment:

This is essentially a duplicate of #11842. In short, slice.indices is working 
as intended here. It's best to think of slice.indices as start, stop and step 
arguments that could be provided to the range built-in function to get the set 
of relevant indices.

--
nosy: +mark.dickinson
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> slice.indices with negative step and default stop

___
Python tracker 
<https://bugs.python.org/issue42467>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42454] Move slice creation to the compiler for constants

2020-11-25 Thread Mark Dickinson


Mark Dickinson  added the comment:

> At least for optimization, IMHO it worth taking the shot.

For me, this feels a bit backwards: IMO you should decide what behaviour you 
want first, implement the desired behaviour, and then optimize (if possible) 
while keeping that same desired behaviour. It's rare that we want an 
optimization to drive behaviour changes.

So for me, the key question that needs answering is: independent of any 
performance changes, do we want the behaviour change? Specifically, do we want 
something like "d = {}; d[1:2] = True" to "work" in Python 3.10, given that in 
previous releases it raises TypeError? What are the potential benefits or 
drawbacks for the user?

If you can get consensus that the behaviour change is fine, then by all means 
go ahead with the optimization. But I think the behaviour question needs to be 
answered first.

--

___
Python tracker 
<https://bugs.python.org/issue42454>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42429] Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal

2020-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

Here's a first draft of proposed re-wording for the 'e', 'f' and 'g' sections 
of the table in the general format-specification mini-language docs. (I started 
making a PR, but got too annoyed with the mechanics of editing reStructuredText 
tables.)


'e': Scientific "E" notation. For a given precision ``p >= 0``, formats the
number in scientific notation with the letter 'e' separating the coefficient
from the exponent. The coefficient has one digit before and ``p`` digits after
the decimal point, for a total of ``p + 1`` significant digits. With no
precision, uses a precision of ``6`` digits after the decimal point for
:class:`float`, and shows all coefficient digits (including any trailing zeros)
for :class:`~decimal.Decimal`.

'f': Fixed-point notation. For a given precision ``p >= 0``, formats the number
as a decimal number with exactly ``p`` digits following the decimal point. With
no precision, uses a precision of ``6`` digits after the decimal point for
:class:`float`, and shows all coefficient digits (including any trailing zeros)
for :class:`~decimal.Decimal`. Note that in the case of a
:class:`~decimal.Decimal` instance with a positive exponent, the formatted
output will consist of the digits of the coefficient sequence extended by
additional zeros: for example, ``format(Decimal('1.23e4'), 'f')`` gives
``'12300'``.

'g': 

A precision of ``0`` is treated as equivalent to a precision of ``1``.
With no precision, uses a precision of ``6`` significant digits for
:class:`float`, and shows all coefficient digits (including any trailing zeros)
for :class:`~decimal.Decimal`.

--

___
Python tracker 
<https://bugs.python.org/issue42429>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42429] Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal

2020-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

There's also #39096.

--

___
Python tracker 
<https://bugs.python.org/issue42429>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42429] Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal

2020-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

Some references after a bit of tracker digging:

- #7098 is the original issue where the behaviour was considered.
- #23460 is related, and _did_ result in a documentation change, but that 
documentation change didn't say anything about preserving trailing zeros
- #13433 is relevant, and still open

So I think we're still missing a documentation update.

--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python
versions: +Python 3.10, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue42429>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42429] Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal

2020-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

Hmm. I'm not sure that it ever got documented properly. There may still be an 
open documentation issue somewhere.

There's not really much wiggle-room for changing the implementation: the 
behaviour of the "g" formatting for Decimal objects is following the 
specification of "to-scientific-string" from the Decimal Arithmetic spec that 
the decimal module is based on: 
http://speleotrove.com/decimal/daconvs.html#reftostr

One of the principles articulated there is that to-scientific-string should be 
faithful, so that conversion to string and back doesn't lose any information. 
That precludes chopping significant trailing zeros.

--

___
Python tracker 
<https://bugs.python.org/issue42429>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42428] Inconsistent squaring behavior

2020-11-21 Thread Mark Dickinson


Mark Dickinson  added the comment:

-3 ** 2 is parsed by Python as -(3 **2), not as (-3) ** 2.

--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue42428>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40633] json.dumps() should encode float number NaN to null

2020-11-20 Thread Mark Dickinson


Mark Dickinson  added the comment:

@Arjan Staring: could you point to which part of the JSON specification you're 
looking at?

At https://tools.ietf.org/html/rfc7159, the only reference to NaNs that I see 
is:

> Numeric values that cannot be represented in the grammar below (such
> as Infinity and NaN) are not permitted.

At https://www.json.org/json-en.html, there's no mention of IEEE 754 special 
values.

I'm not seeing anything anywhere to suggest that the JSON specification says 
NaNs should be translated to nulls.

--

___
Python tracker 
<https://bugs.python.org/issue40633>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX

2020-11-17 Thread Mark Dickinson


Mark Dickinson  added the comment:

[Victor]

> How can we fix the buildbot? Add #ifdef in mathmodule.c to implement the 
> special cases, but only on AIX? Skip the test?

I'm not super-keen on using #ifdefs to implement the special-case handling 
_just_ for AIX: that opens the door to a labyrinth of #ifdef'ery working around 
various different problems on various different platforms. If we're going to 
handle special cases ourselves, let's do it for all platforms.

But I'd also be fine with skipping the test (just on AIX, of course) for now. 
If we can also find a way to remind ourselves to revisit once the upstream bug 
has been fixed, so much the better.

--

___
Python tracker 
<https://bugs.python.org/issue42323>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42334] Subclassing int and complex with keyword arguments weird

2020-11-13 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue42334>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX

2020-11-11 Thread Mark Dickinson


Mark Dickinson  added the comment:

> My worry is that I'm getting emails about AIX buildbot failures.

That sounds more like a process problem than a CPython codebase one. The ideal 
would be that the machinery sending those notifications can be configured to 
ignore known failures when deciding whether to send email. Is that remotely 
feasible? (I have zero familiarity with the buildbot machinery.)

Skipping the test on AIX sounds like a reasonable option, but I kinda *want* 
IBM developers running the Python test suite on AIX to see those failures, in 
the hope that they might then be motivated to push for a fix to the relevant 
AIX bug. :-)

--

___
Python tracker 
<https://bugs.python.org/issue42323>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX

2020-11-11 Thread Mark Dickinson


Mark Dickinson  added the comment:

Is there any reasonable channel for reporting the issue upstream?

--

___
Python tracker 
<https://bugs.python.org/issue42323>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX

2020-11-11 Thread Mark Dickinson


Mark Dickinson  added the comment:

If AIX were one of our officially supported platforms, then yes, I'd say that 
we should add a workaround to handle special cases ourselves, similarly to what 
we already do for a number of math module functions (like math.pow, for 
example).

But given that it's only a "best effort" platform, I'm not convinced that it's 
worth the effort or the extra complication in the codebase.

-0 from me, I guess.

--

___
Python tracker 
<https://bugs.python.org/issue42323>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20543] ** operator does not overflow to inf

2020-11-07 Thread Mark Dickinson


Mark Dickinson  added the comment:

Thanks, @iritkatriel. Sounds good to me.

--
stage:  -> resolved
status: pending -> closed

___
Python tracker 
<https://bugs.python.org/issue20543>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42210] float.hex discards sign from -nan

2020-10-31 Thread Mark Dickinson


Mark Dickinson  added the comment:

This isn't a bug: it was a deliberate decision, just like the choice to 
represent `-nan` as `nan` in `float.__repr__` was a deliberate decision. NaNs 
don't have a meaningful sign - they have a sign *bit*, but it's best to regard 
that as just an extra bit of metadata (like the payload bits).

IEEE 754 explicitly refuses to interpret the sign bit of a NaN: section 1.4 of 
the 2019 version of the standard says: "This standard does not specify [...] 
Interpretation of the sign and significand fields of NaNs."

As Vedran points out, infinities are a very different beast: the difference 
between negative infinity and positive infinity matters.

[Raymond]

> no application should rely on seeing a particular sign for a NaN

Yep, exactly.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42210>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

2020-10-06 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy:  -mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue26680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

2020-10-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

[Guido]

> Possibly at some point in the future we can switch to using typing.Protocol 
> [...]

Yes, I think there's an interesting wider problem here, that typing.Protocol 
might be the answer to.

For numbers and collections.abc in the std. lib., I'm happy to accept that 
simply having a method present in the relevant ABC class implicitly makes it a 
part of the interface (though it would be good if that were clarified 
somewhere).

But in our own code, we've found it convenient to have abc.ABC subclasses that 
are a combination of interface and convenience base class, with the external 
interface separated from the convenience methods via the @abstractmethod and 
@abstractproperty decorators: classes that register with the given ABC subclass 
must provide all methods marked with those decorators, but the other methods 
are not considered part of the formal interface, and not used by client code 
that expects only an object implementing that interface.

The alternative to that convenience is to have two classes: a separate purely 
abstract interface, and a base class implementing that interface that's 
designed for subclassing. That works too, but it's a bit unwieldy, and it's 
useful to have the all-in-one option available.

--

___
Python tracker 
<https://bugs.python.org/issue26680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

2020-10-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

Ok, so we need to either (a) revert PR 6121 and then re-do the changes, without 
the changes to numbers.py, or (b) make a second PR to undo the numbers.py 
changes. I think there's (calendar) time available for option (b), but I'm not 
going to have bandwidth to do it any time soon, so there's a risk that the 
current changes make it into Python 3.10 purely through inertia. What's the 
best approach here?

--

___
Python tracker 
<https://bugs.python.org/issue26680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

2020-10-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

> When a concrete class registers with an ABC, it is making a promise that it 
> implements everything in the ABC.

Ah, interesting. I would have assumed that it's only making a promise that it 
registers all the methods and properties marked *abstract* in the ABC. Do you 
have references to back up the stronger statement?

--

___
Python tracker 
<https://bugs.python.org/issue26680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

2020-10-04 Thread Mark Dickinson


Mark Dickinson  added the comment:

> That still amounts to making it a requirement for all numeric classes

How so? I don't follow the reasoning here.

--

___
Python tracker 
<https://bugs.python.org/issue26680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

2020-10-04 Thread Mark Dickinson


Mark Dickinson  added the comment:

I interpreted "in the numeric tower" as meaning declared as an abstract method 
that all those registering with the class would have to implement. As you point 
out in msg350173, that would be problematic - adding new methods to published 
interfaces is pretty much a no-no for backwards compatibility reasons.

But that's not what happened here. Robert's original patch *did* add is_integer 
as an abstract method. The PR that was merged did not - it was added as a 
concrete method, as a convenience for those using the ABCs via direct 
subclassing rather than registering.

--

___
Python tracker 
<https://bugs.python.org/issue26680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

2020-10-01 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 58a7da9e125422323f79c4ee95ac5549989d8162 by Robert Smallshire in 
branch 'master':
bpo-26680: Incorporate is_integer in all built-in and standard library numeric 
types (GH-6121)
https://github.com/python/cpython/commit/58a7da9e125422323f79c4ee95ac5549989d8162


--

___
Python tracker 
<https://bugs.python.org/issue26680>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41902] Micro optimization for range.index if step is 1

2020-10-01 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Do we need another fast-path in long_div(a, b) when b == _PyLong_One? Just 
> return a in this case.

I'd much prefer not. Every extra fast path check costs time for the general 
case, and there's no strong reason to expect people to be dividing by one. The 
range code seems like the right place for this optimization, not the 
long-divide code.

--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue41902>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41823] Add more fields to sys.float_info

2020-09-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

Double rounding is a property of how operations on floats are carried out, 
rather than being a property of the float format itself; I'm not sure that it 
belongs in float_info. It's also potentially ill-defined. Right now, as far as 
I *know*, it seems to be the case that our builds of CPython on x86 or x64 
either consistently use x87+extended precision for all floating-point 
operations, or they consistently use SSE2 for all floating-point operations, 
but there's no reason that a build couldn't use SSE2 in some cases and 
x87+extended precision in others. (There are also subtle differences between 
x87+53-bit precision setting and IEEE 754-following SSE2.)

We also don't have any _reliable_ way to tell whether floats use IEEE 754, 
though we do have some ad-hoc ways that seem to work in practice (at least for 
now).

--

___
Python tracker 
<https://bugs.python.org/issue41823>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39385] Add an assertNoLogs context manager to unittest TestCase

2020-09-19 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson
nosy_count: 8.0 -> 9.0
pull_requests: +21362
pull_request: https://github.com/python/cpython/pull/22317

___
Python tracker 
<https://bugs.python.org/issue39385>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared

2020-09-04 Thread Mark Dickinson


Change by Mark Dickinson :


--
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue38240>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41487] Builtin bigint modulo operation can be made faster when the base is divisible by a large power of 2 (i.e: has many trailing 0 digits in binary)

2020-08-28 Thread Mark Dickinson


Change by Mark Dickinson :


--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41487>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41598] Adding support for rounding modes to builtin round

2020-08-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

@Vedran:

> I have tons of these ideas, but usually am afraid of voicing them ...

Always good to have ideas brought up, so long as there's no expectation that 
every idea gets implemented. :-) But I think rounding a string is probably 
another one for the python-ideas mailing list. (Personally, I think I'd rather 
have easier ways to create Decimal objects than have strings become a kind of 
proxy for Decimal objects - e.g., `round(2.675d, 2)` rather than 
`round("2.657", 2)`.)

--

___
Python tracker 
<https://bugs.python.org/issue41598>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41598] Adding support for rounding modes to builtin round

2020-08-25 Thread Mark Dickinson


Mark Dickinson  added the comment:

> I don't think that this will be a very difficult feature to implement.

Agreed that it shouldn't be hard to implement, if we do the obvious thing 
(rounding the exact value that the float represents, rather than trying to do 
some sort of Do What I Mean rounding). But I'm far from convinced that it's a 
good idea. I think it'll increase user confusion and generate lots of spurious 
"Python's round is broken" bug reports.

To be clear: supporting rounding modes for rounding from float to integer is 
fine (i.e., supporting the ndigits=0 case, or the case where ndigits is not 
supplied at all). The confusion is going to arise with rounding to a particular 
number of decimal places with a given rounding mode.

Note: there are two parts to this - the first part is figuring out what 
functionality we want. The second part is figuring out how best to spell it 
(separate functions versus keyword arguments to round, etc.). I'm mostly 
ignoring the second part for now and concentrating on the first part. There's a 
lot to discuss with the second part too (e.g., how does the __round__ protocol 
change, in a way that doesn't break 3rd party types already using it; how do we 
specify rounding modes, etc.), but it doesn't seem so useful to have that 
discussion until the first part is figured out.

Two examples to illustrate, one with a round-to-nearest rounding mode, one with 
a directed rounding mode:

- What would you expect round(2.675, ndigits=2, mode=ROUND_HALF_UP) to give? I 
strongly suspect that Marco would expect and want a result of 2.68. But if we 
follow the existing rules for round, it's going to give 2.67.

- What would you expect round(2.712, ndigits=3, mode=ROUND_UP) to give? The 
binary float given by the literal 2.712 is just a touch larger than 2.712, so 
it should round up, giving 2.713. But again, I doubt that's what users will 
expect or want.  Even worse, the rounding is not idempotent: the float 2.713 is 
again a little larger than Decimal("2.713"), so it rounds up again: so if we 
round the value 2.712 twice to 3 digits using ROUND_UP, we'll get 2.714.

Tricks like the power of 10 scaling in the original post aren't really a 
solution: they just serve to make it even less predictable when the users' 
expected result will appear and when it won't, and likely give a false sense of 
security.

If we were to implement this, there's a choice to be made: do we (1) base the 
rounding on the actual float value and do correct rounding, as round currently 
does, or do we (2) try to do something magic that guesses what value the user 
actually meant, rather than rounding the exact value that the round function 
receives? I _really_ _really_ don't want to go down the DWIM path of option 
(2), but I suspect that (1) will be mostly useless for users, outside the 
ndigits=0 use-case. There _are_ valid use-cases for two-argument round on 
floats (e.g., casual binning), but for the most part round already fills those 
use-cases.

I'd rather add whatever bells and whistles we need (if any) to make it easier 
for users who care about this to use Decimal.

--

___
Python tracker 
<https://bugs.python.org/issue41598>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41610] Any Raspberry Pi Zero Projects to try?

2020-08-23 Thread Mark Dickinson


Change by Mark Dickinson :


--
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41610>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41513] Scale by power of two in math.hypot()

2020-08-11 Thread Mark Dickinson


Mark Dickinson  added the comment:

Fine by me in principle; I haven't had a chance to look at the code yet.

While we're doing this, any chance we could special-case the two-argument hypot 
to use the libm hypot directly? On many platforms the libm hypot will be 
correctly rounded, or close to it. There was a noticeable accuracy regression 
for two-argument hypot when hypot gained the ability to support multiple 
arguments.

--

___
Python tracker 
<https://bugs.python.org/issue41513>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41458] Avoid overflow/underflow in math.prod()

2020-08-06 Thread Mark Dickinson


Mark Dickinson  added the comment:

Whoops. There's a missing `count += 1` in there, of course.

--

___
Python tracker 
<https://bugs.python.org/issue41458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41458] Avoid overflow/underflow in math.prod()

2020-08-06 Thread Mark Dickinson


Mark Dickinson  added the comment:

Here's code to illustrate the idea. It doesn't yet handle zeros, infinities or 
nans; that support would need to be added.

import math

def fprod(numbers):
# Product of numbers, avoiding intermediate underflow and overflow.
# Does not handle zeros, infinities or nans

# Running product is acc_m * 2**acc_e
acc_m, acc_e = float.fromhex("1p1000"), -1000

count = 0
for number in numbers:
m, e = math.frexp(number)
acc_m *= m
acc_e += e
if count == 1000:
if acc_m < 1.0:
acc_m = math.ldexp(acc_m, 1000)
acc_e -= 1000
count = 0

return math.ldexp(acc_m, acc_e)

--

___
Python tracker 
<https://bugs.python.org/issue41458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41458] Avoid overflow/underflow in math.prod()

2020-08-06 Thread Mark Dickinson


Mark Dickinson  added the comment:

If we want to do this (and I'm still not convinced that we do), I think there's 
a simpler way: use `frexp` to decompose each float into a fraction and an 
exponent, multiply the fractions (which barring zeros will all be in [0.5, 
1.0)), and keep track of the accumulated exponents separately. Then combine 
everything at the end.

There's a possibility of the accumulated product of the fractions underflowing, 
but only every 1000 floats or so, so it's enough to check every 500 floats 
(say) whether the product is smaller than 2**-500 or not, and scale by 2**1000 
(adjusting the exponent correspondingly) if not.

--

___
Python tracker 
<https://bugs.python.org/issue41458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41487] Builtin bigint modulo operation can be made faster when the base is divisible by a large power of 2 (i.e: has many trailing 0 digits in binary)

2020-08-05 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +tim.peters

___
Python tracker 
<https://bugs.python.org/issue41487>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41485] Repr of complex number with signed zero does not roundtrip

2020-08-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

[META] @Eric: No apology needed. I find the issue tracker search hard to use 
well, and in general we don't do a great job of tracking duplicates properly. 
I'm trying to be better about that.

--

___
Python tracker 
<https://bugs.python.org/issue41485>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41487] Builtin bigint modulo operation can be made faster when the base is divisible by a large power of 2 (i.e: has many trailing 0 digits in binary)

2020-08-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

I'd be opposed to changing Python's `int` implementation in this way: it adds 
complication to the codebase and potentially also slows down "normal" cases. If 
a user knows in advance (a) that they're using a divisor that's highly divisble 
by 2, and (b) that the division or modulo operation is performance critical, 
then they can take the appropriate steps to optimize their code.

--

___
Python tracker 
<https://bugs.python.org/issue41487>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40269] Inconsistent complex behavior with (-1j)

2020-08-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

Updating resolution to "duplicate", in an effort to keep discussion in a single 
place.

--
resolution: not a bug -> duplicate
superseder:  -> Complex number representation round-trip doesn't work with 
signed zero values

___
Python tracker 
<https://bugs.python.org/issue40269>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17336] Complex number representation round-trip doesn't work with signed zero values

2020-08-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

Also related: #40269

--

___
Python tracker 
<https://bugs.python.org/issue17336>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17336] Complex number representation round-trip doesn't work with signed zero values

2020-08-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

The issue of changing the complex repr came up again in #41485, which has been 
closed as a duplicate of this issue.

See also https://bugs.python.org/issue23229#msg233963, where Guido says:

> BTW I don't want repr() of a complex number to use the complex(..., ...)
notation -- it's too verbose.

FWIW, I'd be +1 on changing the complex repr, but given Guido's opposition 
we're probably looking at a PEP to make that happen, and I don't have the 
bandwidth or the energy to push such a PEP through.

--

___
Python tracker 
<https://bugs.python.org/issue17336>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41485] Repr of complex number with signed zero does not roundtrip

2020-08-05 Thread Mark Dickinson


Mark Dickinson  added the comment:

Closing here; to the extent that it's possible, let's keep the discussion in 
one place (comments can still be posted on closed issues). I'll add a comment 
on #17336.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Complex number representation round-trip doesn't work with 
signed zero values

___
Python tracker 
<https://bugs.python.org/issue41485>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41485] Repr of complex number with signed zero does not roundtrip

2020-08-05 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue41485>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41458] Avoid overflow/underflow in math.prod()

2020-08-03 Thread Mark Dickinson


Mark Dickinson  added the comment:

This message from Tim, starting "I'd like to divorce `prod()` from 
floating-point complications", seems relevant here: 
https://bugs.python.org/issue35606#msg333090

--

___
Python tracker 
<https://bugs.python.org/issue41458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36788] Add clamp() function to builtins

2020-07-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

Another python-ideas thread, from 2016: 
https://mail.python.org/archives/list/python-id...@python.org/thread/EHZAXE4P2VOT3CE4H6SNDPDASW7H2CGS/

--

___
Python tracker 
<https://bugs.python.org/issue36788>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41408] Add a `clamp` function to the `math` module

2020-07-28 Thread Mark Dickinson


Change by Mark Dickinson :


--
resolution: rejected -> duplicate
superseder:  -> Add clamp() function to builtins

___
Python tracker 
<https://bugs.python.org/issue41408>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36788] Add clamp() function to builtins

2020-07-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

#41408 was closed as a duplicate of this issue

See also the recent discussion on python-ideas at 
https://mail.python.org/archives/list/python-id...@python.org/thread/KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS/#KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS

That discussion has petered out without a clear consensus. The next step would 
likely be for an interested party to put together a PEP.

--

___
Python tracker 
<https://bugs.python.org/issue36788>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41342] Convert int.__round__ to Argument Clinic

2020-07-19 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue41342>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41313] sys.setrecursionlimit: OverflowError still raised when int limited in sys.maxsize

2020-07-16 Thread Mark Dickinson


Mark Dickinson  added the comment:

Setting to pending; I don't see any bug here, and I suspect the original report 
was based on a misunderstanding of what sys.setrecursionlimit is for.

--
resolution:  -> not a bug
status: open -> pending

___
Python tracker 
<https://bugs.python.org/issue41313>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41310] micro-optimization: increase our float parsing speed by Nx

2020-07-16 Thread Mark Dickinson


Mark Dickinson  added the comment:

Is there a description of the algorithms or ideas used anywhere? The blog post 
you link to has no details, and I don't see any useful descriptions in the 
GitHub README or the source; trawling through the source to figure out what the 
key ideas are is not ideal. I don't find the tests particularly convincing, 
either.

I think this is too immature to consider for CPython, right now. Maybe it would 
make sense to revisit some day in the future if/when the library is more mature.

--

___
Python tracker 
<https://bugs.python.org/issue41310>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41313] OverflowError still raised when int limited in sys.maxsize

2020-07-16 Thread Mark Dickinson


Mark Dickinson  added the comment:

The recursion depth and recursion limit are stored internally as C ints, so 
yes, 2**31 - 1 = 2147483647 is the maximum value that you can pass to 
`sys.setrecursionlimit` that won't fail immediately.

But it's unclear why you'd ever want to set the recursion limit that high. 
What's your goal here? Are you looking for a way to effectively disable that 
recursion limit altogether? If so, can you explain the use-case?

Note that the recursion limit is there to prevent your code from exhausting the 
C stack and segfaulting as a result: simply setting that limit to a huge value 
won't (by itself) allow you to run arbitrarily deeply nested recursions. On my 
machine, without the protection of the recursion limit, a simple recursive call 
segfaults at around a depth of 30800.

--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue41313>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41269] Wrong subtraction calculations

2020-07-10 Thread Mark Dickinson


Mark Dickinson  added the comment:

Thanks for the report. This isn't a Python bug, but a common issue when working 
with floating-point numbers.

I recommend taking a look at this section of the tutorial for more information: 
https://docs.python.org/3.8/tutorial/floatingpoint.html

--
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41269>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41245] cmath module documentation is misleading on branch cuts

2020-07-08 Thread Mark Dickinson


Mark Dickinson  added the comment:

> [...] see the change of sign in the real part below [...]

Grr. Stupid fingers. That should say "imaginary part", not "real part"

--

___
Python tracker 
<https://bugs.python.org/issue41245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41245] cmath module documentation is misleading on branch cuts

2020-07-08 Thread Mark Dickinson


Mark Dickinson  added the comment:

Yes, that looks like the right part of the sqrt code.

For the acos docstring, "continuous from below" implies that for any complex 
number z that lies exactly _on_ the branch cut, acos(z) is close to acos(w) for 
a nearby value w just _below_ the branch cut. But that's demonstrably not true: 
see the change of sign in the real part below:

>>> acos(complex(2.3, -1e-10))  # value just "below" the branch cut
(4.828045495852677e-11+1.475044781241425j)
>>> acos(complex(2.3, 0.0))  # nearby value exactly _on_ the branch cut
-1.475044781241425j

In effect, for a branch cut along the real axis, the sign of the zero in the 
imaginary part of the argument allows us to be continuous from both sides at 
once.

--

___
Python tracker 
<https://bugs.python.org/issue41245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41245] cmath module documentation is misleading on branch cuts

2020-07-08 Thread Mark Dickinson


Change by Mark Dickinson :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.10, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue41245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41245] cmath module documentation is misleading on branch cuts

2020-07-08 Thread Mark Dickinson


Mark Dickinson  added the comment:

> the sign of x is used [...]

Correction: That should say "the sign of the imaginary part of x is used [...]"

--

___
Python tracker 
<https://bugs.python.org/issue41245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41245] cmath module documentation is misleading on branch cuts

2020-07-08 Thread Mark Dickinson

New submission from Mark Dickinson :

The documentation for the cmath module is misleading on the behaviour near 
branch cuts. For example, the documentation for cmath.acos says:

   Return the arc cosine of x. There are two branch cuts: One
   extends right from 1 along the real axis to ∞, continuous
   from below. The other extends left from -1 along the real
   axis to -∞, continuous from above.

That "continuous from below" and "continuous from above" language is 
misleading; in fact what happens on the vast majority of systems (those for 
which the floating-point format used is IEEE 754 binary64), if the imaginary 
part of x is zero, the sign of x is used to determine which side of the branch 
cut x lies.

--
messages: 373323
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: cmath module documentation is misleading on branch cuts

___
Python tracker 
<https://bugs.python.org/issue41245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)

2020-07-07 Thread Mark Dickinson


Mark Dickinson  added the comment:

@JD-Veiga: would you be willing to work on a PR?

--

___
Python tracker 
<https://bugs.python.org/issue41205>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)

2020-07-04 Thread Mark Dickinson


Mark Dickinson  added the comment:

I agree that the result is surprising and should be noted in the docs; we 
shouldn't expect all the decimal users to be familiar with the specification. 
Some of the other differences with float arithmetic *are* noted (e.g., the 
behaviour of `//` and `%`), but apparently not this one. We do document the 
behaviour of these corner cases for `math.pow`.

The part that I find really odd is that the specification says that 
`Decimal("inf")**Decimal(0)` is `1`. Treating one of 0**0 and inf**0 as 
undefined but not the other seems inconsistent to me. We'd probably want to 
note the behaviour of inf**0 in the docs, too. (I tried to argue with Mike 
Cowlishaw about this, but I lost.)

I'm not sure whether just noting this in the "power" documentation is enough: 
it's not clear to me that users using the ** operator would think to check the 
docs for the "power" method.

The other weirdly non-IEEE 754 behaviour (again, mandated by the standard) that 
bugs me from time to time is that the unary `-` and `+` operators will never 
give negative zero: Decimal("-0.0") and -Decimal("0.0") are not the same thing. 
That one's probably worth noting, too.

--

___
Python tracker 
<https://bugs.python.org/issue41205>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41198] Round built-in function not shows zeros acording significant figures and calculates different numbers of odd and even

2020-07-03 Thread Mark Dickinson


Mark Dickinson  added the comment:

Just for fun, I posted a Stack Overflow question: 
https://stackoverflow.com/q/62721186/270986

Let's close this here.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41198>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41198] Round built-in function not shows zeros acording significant figures and calculates different numbers of odd and even

2020-07-03 Thread Mark Dickinson


Mark Dickinson  added the comment:

One note: in the original post, not only are the values being tested coming 
from NumPy's arange, but round(x[i],1) is testing *NumPy's* rounding 
functionality, not Python's. x[i] has type np.float64, and while np.float64 
does inherit from Python's float, it also overrides float.__round__ with its 
own implementation (that essentially amounts to scale-by-power-of-ten, 
round-to-nearest-int, unscale, just like Python used to do in the bad old 
days). So errors from arange plus NumPy's non-correctly-rounded round means 
that all bets are off on what happens for values that _look_ as though they're 
ties when shown in decimal, but aren't actually ties thanks to the 
what-you-see-is-not-what-you-get nature of binary floating-point.

On arange in particular, I've never looked closely into the implementation; 
it's never noticeably not been "close enough" (i.e., accurate to within a few 
ulps either way), and I've never needed it or expected it to be perfectly 
correctly rounded. Now that it's been brought up, I'll take a look. (But that 
shouldn't keep this issue open, since that's a pure NumPy issue.)

Honestly, given the usual floating-point imprecision issues, I'm surprised that 
the balance is coming out as evenly as it is in Tim's and Steven's experiments. 
I can see why it might work for a single binade, but I'm at a loss to explain 
why you'd expect a perfect balance across several binades. 

For example: if you're looking at values of the form 0.xx5 in the binade [0.5, 
1.0], and rounding those to two decimal places, you'd expect perfect parity, 
because if you pair the values from [0.5, 0.75] with the reverse of the values 
from [0.75, 1.0], in each pair exactly one of the two values will round up, and 
one down (the paired values always add up to *exactly* 1.5, with no rounding, 
so the errors from the decimal-to-binary rounding will always go in opposite 
directions). For example 0.505 rounds up, and dually 0.995 rounds down. (But 
whether the pair gives (up, down) or (down, up) will depend on exactly which 
way the rounding went when determining the nearest binary64 float, so will be 
essentially unpredictable.)

>>> test_values = [x/1000 for x in range(505, 1000, 10)]
>>> len(test_values)  # total count of values
50
>>> sum(round(val, 2) > val for val in test_values)  # number rounding up
25

But then you need to make a similar argument for the next binade down: [0.25, 
0.5] (which doesn't work at all in this case, because that binade contains an 
odd number of values).

Nevertheless, this *does* seem to work, and I haven't yet found a good 
explanation why. Any offers?

>>> k = 8
>>> test_values = [x/10**(k+1) for x in range(5, 10**(k+1), 10)]
>>> sum(round(val, k) > val for val in test_values)
5000

BTW, yes, I think this issue can be closed.

--

___
Python tracker 
<https://bugs.python.org/issue41198>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41100] Build failure on macOS 11 (beta)

2020-07-01 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue41100>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39699] Some CIs silence potentially useful output from make

2020-06-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

The text "TEST CHANGE TO BE UNDONE" is currently visible here: 
https://docs.python.org/3/whatsnew/3.0.html

It was introduced in commit 343bc06d8047e4a2e675394528dbb5155be1b3b5.

Should this test change have been undone?

--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue39699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41090] Support for "Apple Silicon"

2020-06-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

> a bit off-topic for this issue

Apologies: on reflection, it's way off-topic. Please ignore this and the last 
message; I'll find a more appropriate place to take this up.

--

___
Python tracker 
<https://bugs.python.org/issue41090>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41090] Support for "Apple Silicon"

2020-06-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

@Ronald: a bit off-topic for this issue, but do you know if there are or will 
be any publicly available developer resources for people moving to Apple 
Silicon? For obvious reasons, I'm interested in what the floating-point and 
libm situation is going to look like.

--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue41090>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41057] Division error

2020-06-20 Thread Mark Dickinson


Mark Dickinson  added the comment:

This isn't a bug in Python; it's a consequence of the 
what-you-see-is-not-what-you-get nature of binary floating-point.

The behaviour is explained in the tutorial, here: 
https://docs.python.org/3/tutorial/floatingpoint.html

--
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41057>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40999] implicit-int-float-conversion warnings in time and math code

2020-06-17 Thread Mark Dickinson


Mark Dickinson  added the comment:

I think #39277 is related.

--
nosy: +vstinner

___
Python tracker 
<https://bugs.python.org/issue40999>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29882] Add an efficient popcount method for integers

2020-05-31 Thread Mark Dickinson


Mark Dickinson  added the comment:

A couple of other data points:

- Swift has nonzeroBitCount: 
https://developer.apple.com/documentation/swift/int/2886050-nonzerobitcount

- Rust has count_ones: https://doc.rust-lang.org/std/primitive.u64.html

- Go's math/bits package has OnesCount

- The closest thing in Mathematica appears to be DigitCount, which isn't 
base-specific.

@Mark Shannon: what name would you suggest, and why? The term "population 
count" feels too non-obvious and specialist to me, and anything involving 
"Hamming" likewise.

"count_ones" isn't obviously a bit operation.

"count_set_bits"?

--

___
Python tracker 
<https://bugs.python.org/issue29882>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29882] Add an efficient popcount method for integers

2020-05-31 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Why are calling a population count method "bit_count()"?

Naming things is hard, but I don't think this is an unreasonable name, and it's 
not without precedent. Java similarly has Integer.bitCount and 
BigInteger.bitCount. MySQL has BIT_COUNT.

--

___
Python tracker 
<https://bugs.python.org/issue29882>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29882] Add an efficient popcount method for integers

2020-05-29 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 8bd216dfede9cb2d5bedb67f20a30c99844dbfb8 by Niklas Fiekas in 
branch 'master':
bpo-29882: Add an efficient popcount method for integers (#771)
https://github.com/python/cpython/commit/8bd216dfede9cb2d5bedb67f20a30c99844dbfb8


--

___
Python tracker 
<https://bugs.python.org/issue29882>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29882] Add an efficient popcount method for integers

2020-05-29 Thread Mark Dickinson


Change by Mark Dickinson :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.7

___
Python tracker 
<https://bugs.python.org/issue29882>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40780] float.__format__() handles trailing zeros inconsistently in “general” format

2020-05-29 Thread Mark Dickinson


Mark Dickinson  added the comment:

Fixed in master and 3.9; not backporting to 3.8 or 3.7, as discussed.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40780] float.__format__() handles trailing zeros inconsistently in “general” format

2020-05-29 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset ad088ca5c6adc4a107411cad62b83f5c6e06b5ed by Miss Islington (bot) 
in branch '3.9':
bpo-40780: Fix failure of _Py_dg_dtoa to remove trailing zeros (GH-20435) 
(GH-20514)
https://github.com/python/cpython/commit/ad088ca5c6adc4a107411cad62b83f5c6e06b5ed


--

___
Python tracker 
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40780] float.__format__() handles trailing zeros inconsistently in “general” format

2020-05-29 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 895c9c1d438367722f74f437fda96767d770662b by Mark Dickinson in 
branch 'master':
bpo-40780: Fix failure of _Py_dg_dtoa to remove trailing zeros (GH-20435)
https://github.com/python/cpython/commit/895c9c1d438367722f74f437fda96767d770662b


--

___
Python tracker 
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40793] print() performance problem with very large numbers

2020-05-29 Thread Mark Dickinson


Mark Dickinson  added the comment:

> FYI, printing this 60 Million digit number took about 12 hours on my i7.

That sounds about right: on my machine, it takes around 10 seconds to convert a 
1 million-digit number to a string. Multiplying by 60**2 gives 10 hours.

I do have to wonder what you're doing with all those digits now that you have 
them, though ...

--

___
Python tracker 
<https://bugs.python.org/issue40793>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_AsDouble at Python level: operator.as_float?

2020-05-29 Thread Mark Dickinson


Mark Dickinson  added the comment:

I started a python-ideas thread: 
https://mail.python.org/archives/list/python-id...@python.org/thread/3YGNHGWZOU5AIBS3A52CAHPJJLY7J2CS/

--

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_AsDouble at Python level: operator.as_float?

2020-05-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Converting Decimal, Fraction, float128 to float before using it in expression 
> can lead to loss of precision.

My experience is that this loss of precision is hardly ever a practical problem 
in the real world of scientific development; in practice floating-point numbers 
 are almost universally IEEE 754 doubles (perhaps sometimes single-precision in 
large datasets, like seismic SEG-Y files; occasionally IBM format hex floats; 
but IEEE 754 doubles are by far the majority). It's very rare to be using 
float128 or Decimal or Fraction in practice for scientific data.

That's not to say that people outside that world won't be using these things, 
but there's a big ecosystem where float64 is pretty much all you need.

--

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_AsDouble at Python level: operator.as_float?

2020-05-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

> So such conversion looks to me less useful than operator.index().

That may be true, but it's still useful, and currently very hard to write 
without core Python support. The problem is that duck-typing for something 
float-like is easy and widespread in the Python C code (in the math module, in 
float formatting, in *any* function that uses the "d" converter with 
PyArg_ParseTuple), but it's hard to correctly spell the equivalent in pure 
Python.

I've needed this in a few places. Most recently, I needed it for the Enthought 
Traits library: the "Float" trait type accepts something float-like and needs 
to convert it to something of exact Python type float. (That float is then 
often consumed by other third-party libraries that can't reliably be expected 
to do their own duck-typing.)

It would also be useful when trying to create pure Python equivalents for 
modules written in C (e.g., for things like datetime and decimal). Where the C 
code uses PyFloat_AsDouble, there's really no equivalent that can be used in 
Python.

--

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_ToDouble at Python level: operator.as_float?

2020-05-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

On naming, maybe float.from_number or float.from_numeric?

--

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_ToDouble at Python level: operator.as_float?

2020-05-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

> `operator` seems a slightly odd place for this.

Yes, it's not ideal. It's by analogy with operator.index, which provides the 
equivalent duck-typing for integers, and calls __index__.  Similarly, 
operator.as_float is primarily there to call __float__, except that now that 
PyFloat_AsDouble also makes use of __index__, it'll call that, too.

My other thought was putting this in math, since it's what the math module is 
already doing implicitly to most inputs.

An alternative float constructor could work. Though we then run into the messy 
question of what it should do for float subclasses ...

--

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie)

2020-05-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

> The other way to solve my problem would be to provide an operator module 
> function (operator.as_float?) that does a duck-typed conversion of an 
> arbitrary Python object to a float.

This does feel like the *right* solution to me. See #40801 and the linked PR. 
If we can do something like this, I'd be happy to drop the expectation that 
__float__ return something of exact type float, and similarly for __index__.

--

___
Python tracker 
<https://bugs.python.org/issue17576>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_ToDouble at Python level: operator.as_float?

2020-05-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

Proof of concept in GH-20481

--

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_ToDouble at Python level: operator.as_float?

2020-05-28 Thread Mark Dickinson


Change by Mark Dickinson :


--
keywords: +patch
pull_requests: +19730
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/20481

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_ToDouble at Python level: operator.to_float?

2020-05-28 Thread Mark Dickinson


New submission from Mark Dickinson :

Motivation
--

Various pieces of Python need to do a duck-typed conversion of an arbitrary 
float-like object to a float (or a C double) for computation. The math module 
is the most obvious example - most math-module functions that accept a float 
also accept float-like things, like np.float32 and Decimal - but it's not the 
only place that this is needed.

This conversion is easy at C level, being encapsulated in a single function 
call: PyFloat_AsDouble. (Plus a PyFloat_FromDouble if you want to go back to 
Python space, of course.)

But: it's surprisingly awkward to get an equivalent effect in pure Python code. 
Options are:

1. Do an explicit type check to exclude str, bytes and bytearray, and then call 
the float constructor. But the extra type check is ugly and potentially not 
future-proof.

2. Call type(obj).__float__(obj). But this has several problems: __float__ can 
return an instance of a float subclass rather than a strict float, and then 
it's hard to convert to an actual float. And in more recent versions of Python, 
this no longer matches PyFloat_AsDouble because it doesn't account for objects 
that provide __index__ but not __float__. And calling dunder methods directly 
should rarely be the Right Way To Do It.

3. Use the implicit ability of the math module to do this, for example using 
math.copysign(obj, obj). This works! But it's not a clear expression of the 
intent.

This has bitten me in Real Code (TM), where I've needed a way to convert an 
arbitrary float-like thing to a float, ideally following the same rules that 
Python uses. And also ideally in such a way that my own code doesn't have to 
change if Python updates its rules, as for example it did recently to allow 
things with an __index__ to be considered float-like.


Proposal


Add a new operator function "operator.as_float" which matches Python's 
duck-typed acceptance of float-like things, in the same way that the existing 
operator.index matches Python's implicit acceptance of int-like things in 
various APIs that expect integers.

Internally, "operator.as_float" would simply call PyFloat_AsDouble followed by 
PyFloat_FromDouble (possibly with a fast path to pass objects of exact type 
float through directly).



Related: #17576.

--
messages: 370181
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Expose PyFloat_ToDouble at Python level: operator.to_float?
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40801] Expose PyFloat_ToDouble at Python level: operator.as_float?

2020-05-28 Thread Mark Dickinson


Change by Mark Dickinson :


--
title: Expose PyFloat_ToDouble at Python level: operator.to_float? -> Expose 
PyFloat_ToDouble at Python level: operator.as_float?

___
Python tracker 
<https://bugs.python.org/issue40801>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie)

2020-05-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

[Serhiy]

> * Undeprecate accepting __index__ and __int__ returning instances of int 
> sublasses. There is no difference from the side of using int and index(), but 
> it can simplify user implementations of __index__ and __int__.

I'm not sure about this. Thinking about the bigger picture, we have a similar 
deprecation in place for __float__ returning an instance of a float subclass. 
That one I'd like to keep (and probably make an error for 3.10).

A problem I've run into in Real Code (TM) is needing to convert something 
float-like to a float, using the same mechanisms that (for example) something 
like `math.sqrt` uses.

One option is to call "float", but that requires explicitly excluding str, 
bytes and bytearray, which feels ugly and not very future-proof.

So the code ends up calling __float__. But because __float__ can return an 
instance of a float subclass, it then still needs some way to convert the 
return value to an actual float. And that's surprisingly tricky.

So I really *do* want to see the ability of __float__ to return a non-float 
eventually removed.

Similarly for __int__, there's no easy Python-side way to mimic the effect of 
calling __int__, followed by converting to an exact int. We have to:

1. Do an explicit check for non-numbers (str, bytes, bytearray)
2. Call int

Or:

1. Call __int__
2. Convert an instance of a possible subclass of int to something of exact type 
int. I don't know how to do this cleanly in general in Python, and end up 
resorting to evil tricks like adding `0`.

Deprecating allowing __int__ to return a non-int helps here, because it lets me 
simply call __int__.

I care much more about the __float__ case than the __int__ case, because the 
"right way" to duck-type integers is to use __index__ rather than __int__, and 
for __index__ we have operator.index as a solution.

But it would seem odd to have the rule in place for __float__ but not for 
__int__ and __index__.


The other way to solve my problem would be to provide an operator module 
function (operator.as_float?) that does a duck-typed conversion of an arbitrary 
Python object to a float.

--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue17576>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40780] float.__format__() handles trailing zeros inconsistently in “general” format

2020-05-27 Thread Mark Dickinson


Change by Mark Dickinson :


--
versions:  -Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37999] No longer use implicit convertion to int with loss

2020-05-27 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 20941de0ddc39ce9f07e29b4cc770e8a9ef14d41 by Mark Dickinson in 
branch 'master':
bpo-37999: Fix outdated __int__ and nb_int references in comments (GH-20449)
https://github.com/python/cpython/commit/20941de0ddc39ce9f07e29b4cc770e8a9ef14d41


--

___
Python tracker 
<https://bugs.python.org/issue37999>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40792] Make PyNumber_Index() always returning an exact int instance

2020-05-27 Thread Mark Dickinson


Mark Dickinson  added the comment:

The behaviour change for range sounds reasonable to me.

Just to make sure I understand the impact of the change:

- For Python < 3.10, we sometimes convert the range inputs to Python ints, and 
sometimes don't. For example, a start value of `np.int64(5)` would be 
converted, but a value of `True` would not be.

- With this change, we'd always convert a non-int to an int, so both 
`np.int64(1)` and `True` would be converted to a `1` of exact type int.

IMO this is fine; the new behaviour seems more consistent than the old.

>>> import numpy as np
>>> start = np.int64(2)
>>> range(start, 5).start is start
False
>>> start = True
>>> range(start, 5).start is start
True

--

___
Python tracker 
<https://bugs.python.org/issue40792>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40793] print() performance problem with very large numbers

2020-05-27 Thread Mark Dickinson


Mark Dickinson  added the comment:

Right; the naive algorithm for converting the internal binary representation to 
the decimal representation is quadratic time. In *theory* we could implement a 
subquadratic time algorithm, but the complexity of such an implementation 
outweighs the benefits. Python really isn't targeted at super-fast 
million-digit arithmetic; that's more the domain of libraries like GMP.

Closing as "won't fix". I'd recommend using gmpy2[1] instead. Alternatively, 
you may be able to make the `Decimal` type work with a suitably huge precision.

Related: #26256.

[1] gmpy2: https://gmpy2.readthedocs.io/en/latest/intro.html

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40793>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37999] No longer use implicit convertion to int with loss

2020-05-27 Thread Mark Dickinson


Change by Mark Dickinson :


--
pull_requests: +19703
pull_request: https://github.com/python/cpython/pull/20449

___
Python tracker 
<https://bugs.python.org/issue37999>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37999] No longer use implicit convertion to int with loss

2020-05-27 Thread Mark Dickinson


Mark Dickinson  added the comment:

There are some comments in the Objects/longobject.c code that still refer to 
__int__, and could use an update.

For example: 
https://github.com/python/cpython/blob/7da46b676aed7111de34b57c8b942a7f3bb80327/Objects/longobject.c#L366

--
nosy: +mark.dickinson

___
Python tracker 
<https://bugs.python.org/issue37999>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40780] str.format() handles trailing zeros inconsistently in “general” format

2020-05-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

I'm wondering how far back the fix should be backported. Clearly it should go 
into the 3.9 branch as well as master, but it feels like the sort of fix where 
the behaviour change resulting from the fix is as likely to break code as the 
bug itself.

--

___
Python tracker 
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   5   6   7   8   9   10   >