[issue7946] Convoy effect with I/O bound threads and New GIL

2021-12-05 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

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



[issue45476] [C API] PEP 674: Disallow using macros as l-value

2021-12-02 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy:  -mark.dickinson

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



[issue45917] Add math.exp2() function: 2^x

2021-11-30 Thread Mark Dickinson


Mark Dickinson  added the comment:

[Tim]

> on Windows, exp2(x) is way worse then pow(2, x)

Darn.

> I expect we should just live with it.

Agreed.

--

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



[issue45917] Add math.exp2() function: 2^x

2021-11-29 Thread Mark Dickinson


Mark Dickinson  added the comment:

All done. Many thanks, Gideon!

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

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



[issue45917] Add math.exp2() function: 2^x

2021-11-29 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 6266e4af873a27c9d352115f2f7a1ad0885fc031 by Gideon in branch 
'main':
bpo-45917: Add math.exp2() method - return 2 raised to the power of x (GH-29829)
https://github.com/python/cpython/commit/6266e4af873a27c9d352115f2f7a1ad0885fc031


--

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



[issue45917] Add math.exp2() function: 2^x

2021-11-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

On the subject of accuracy, there doesn't seem to be much in it on my mac 
laptop, and it looks as though pow(2.0, x) is giving correctly rounded results 
as often as (if not more often than) exp2(x).

Here's the log of a terminal session, after recompiling Python to add exp2. It 
shows the ulps error (tested against a high-precision Decimal computation, 
which we're treating as representing the "exact" result) for both exp2(x) and 
pow(2.0, x) when the two results differ, for a selection of randomly chosen x 
in the range(-1000.0, 1000.0). Columns in the output are:

x (in hex), x (in decimal), ulps error in exp2(x), ulps error in pow(2.0, x)

>>> from decimal import getcontext, Decimal
>>> from math import exp2, pow, ulp
>>> import random
>>> getcontext().prec = 200
>>> def exp2_error_ulps(x):
... libm = exp2(x)
... exactish = 2**Decimal(x)
... return float(Decimal(libm) - exactish) / ulp(libm)
... 
>>> def pow2_error_ulps(x):
... libm = pow(2.0, x)
... exactish = 2**Decimal(x)
... return float(Decimal(libm) - exactish) / ulp(libm)
... 
>>> for n in range(1):
... x = random.uniform(-1000.0, 999.0) + random.random()
... if exp2(x) != pow(2.0, x):
... print(f"{x.hex():21} {x:22.17f} {exp2_error_ulps(x): .5f}, 
{pow2_error_ulps(x): .5f}")
... 
0x1.e28f2ad3da122p+560.31990590581177969  0.50669, -0.49331
-0x1.929e790e1d293p+9 -805.23806930946227567  0.50082, -0.49918
-0x1.49803564f5b8ap+8 -329.50081473349621319  0.49736, -0.50264
-0x1.534cf08081f4bp+8 -339.30054476902722627 -0.50180,  0.49820
-0x1.b430821fb4ad2p+8 -436.18948553238908517 -0.49883,  0.50117
0x1.2c87a8431bd8fp+8   300.52991122655743084 -0.50376,  0.49624
0x1.3e476f9a09c8cp+7   159.13952332848964488  0.50062, -0.49938
0x1.cb8b9c61e7e89p+9   919.09070991347937252  0.49743, -0.50257
0x1.ab86ed0e6c7f6p+9   855.05410938546879152  0.49742, -0.50258
0x1.97bc9af3cbf85p+9   815.47347876986952997 -0.50076,  0.49924
-0x1.b5434441ba11bp+8 -437.26276026528074681 -0.50062,  0.49938
-0x1.0ead35218910ep+9 -541.35318392937347198  0.50192, -0.49808
-0x1.dbae0b861b89cp+9 -951.35972668022759535  0.50601, -0.49399
0x1.522f005d2dcc4p+684.54589982597377684 -0.50704,  0.49296
0x1.398ff48d53ee1p+9   627.12465063665524667 -0.50102,  0.49898
-0x1.381307fbd89f5p+5  -39.00929257159069863 -0.50526,  0.49474
0x1.9dc4c85f7c53ap+9   827.53736489840161994 -0.50444,  0.49556
0x1.b357f6012d3c2p+9   870.68719496449216422 -0.50403,  0.49597
-0x1.a6446703677bbp+9 -844.53439371636284250  0.50072, -0.49928
0x1.e3dd54b28998bp+7   241.93228681497234334  0.49897, -0.50103
0x1.b4f77f18a233ep+8   436.96678308448815642  0.49593, -0.50407
-0x1.578c4ce7a7c1bp+3  -10.73587651486564276 -0.50505,  0.49495
0x1.25a9540e1ee65p+536.70767985374258302  0.49867, -0.50133
-0x1.6e220f7db7668p+8 -366.13304887511776542 -0.49904,  0.50096
-0x1.94214ed3e5264p+9 -808.26021813095985635  0.50420, -0.49580
0x1.9dcc3d281da18p+551.72472602215219695 -0.50423,  0.49577
-0x1.3ba66909e6a40p+7 -157.82502013149678532 -0.50077,  0.49923
-0x1.9eac2c52a1b47p+9 -829.34510262389892432 -0.50540,  0.49460

--

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



[issue45917] Add math.exp2() function: 2^x

2021-11-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

See also previous discussion towards the end of 
https://bugs.python.org/issue3366.

FWIW, I don't think there's value in adding exp2 to the cmath module too: we'd 
have to write our own implementation, and it's just not a function that appears 
often in the complex world.

--

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



[issue45917] Add math.exp2() function: 2^x

2021-11-28 Thread Mark Dickinson

Mark Dickinson  added the comment:

Sounds good to me, provided that all the common platforms that we care about 
have a reasonable quality implementation. This should be a straightforward 
wrapping of the C99 function, and with sufficient tests the buildbots should 
tell us if there are any issues on common platforms.

@Gideon: are you're interested in working on a pull request? I'd be happy to 
review.

(Ideally I'd like to have exp10 too, but that's not in C99 so platform support 
is likely to be spotty. If anyone's interested in pursuing that, we should make 
it a separate issue.)

> a libm exp2 is supposedly more accurate than pow(2.0, x), though I don’t 
> really see how this would be the case

pow is a difficult function to implement at high accuracy, and there are a good 
number of low quality pow implementations around in system math libraries. It's 
much easier to come up with a high accuracy implementation of a single-argument 
function - there are well known techniques for generating approximating 
polynomials that simply don't extend well to functions of two arguments.

sqrt is similar: pow(x, 0.5) is very often not correctly rounded even on 
systems where sqrt(x) _is_. (Though that one's a bit of a cheat, since common 
processors have dedicated instructions for a correctly-rounded sqrt.)

--

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



[issue45739] The Python implementation of Decimal does not support the "N" format

2021-11-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

I could be persuaded for any of options -1, 1 and 2. I don't much like option 0.

--

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



[issue45739] The Python implementation of Decimal does not support the "N" format

2021-11-28 Thread Mark Dickinson


Mark Dickinson  added the comment:

Eric, Serhiy: do you have opinions on the right way forward?

Here are 6 options, on a spectrum of increasing level of acceptance of "N".

-2. Remove "N" support for cdecimal right now (i.e., for Python 3.11), on the 
basis that there's no need for deprecation warnings, because it was never 
officially a feature.
-1. Deprecate "N" support for cdecimal, remove it in Python 3.13.
0. Do nothing (the default), leaving _pydecimal and cdecimal inconsistent.
1. Add "N" support to the Python implementation for parity with cdecimal, but 
don't document it - leave it as an undocumented feature.
2. Officially add "N" support to decimal formatting - add documentation, tests, 
and fix the Python implementation.
3. Officially add "N" support to all numeric formatting ...

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

Concrete example of int/int not being correctly rounded on systems using x87 
instructions: on those systems, I'd expect to see 1/2731 return a result of 
0.00036616623947272064 (0x1.7ff4005ffd002p-12), as a result of first rounding 
to 64-bit precision and then to 53-bit. The correctly-rounded result is 
0.0003661662394727206 (0x1.7ff4005ffd001p-12).

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

> All the rounding has already happened at the point where ldexp is called, and 
> the result of the ldexp call is exact.

Sketch of proof:

[Here](https://github.com/python/cpython/blob/4ebde73b8e416eeb1fd5d2ca3283f7ddb534c5b1/Objects/longobject.c#L3929)
 we have:

shift = Py_MAX(diff, DBL_MIN_EXP) - DBL_MANT_DIG - 2;

from which (assuming IEEE 754 as usual) shift >= -1076. (DBL_MIN_EXP = -1021, 
DBL_MANT_DIG = 53)

[Here](https://github.com/python/cpython/blob/4ebde73b8e416eeb1fd5d2ca3283f7ddb534c5b1/Objects/longobject.c#L4008)
 we round away the last two or three bits of x, after which x is guaranteed to 
be a multiple of 4:

x->ob_digit[0] = low & ~(2U*mask-1U);

Then after converting the PyLong x to a double dx with exactly the same value 
[here](https://github.com/python/cpython/blob/4ebde73b8e416eeb1fd5d2ca3283f7ddb534c5b1/Objects/longobject.c#L4020)
 we make the ldexp call:

result = ldexp(dx, (int)shift);

At this point dx is a multiple of 4 and shift >= -1076, so the result of the 
ldexp scaling is a multiple of 2**-1074, and in the case of a subnormal result, 
it's already exactly representable.


For the int/int division possibly not being correctly rounded on x87, see 
[here](https://github.com/python/cpython/blob/4ebde73b8e416eeb1fd5d2ca3283f7ddb534c5b1/Objects/longobject.c#L3889-L3892).

It won't affect _this_ application, but possibly we should fix this anyway. 
Though the progression of time is already effectively fixing it for us, as x87 
becomes less and less relevant.

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Will it suffer the same issues with subnormals on Windows?

No, it should be fine. All the rounding has already happened at the point where 
ldexp is called, and the result of the ldexp call is exact.

> Is CPython int/int true division guaranteed to be correctly rounded?

Funny you should ask. :-) There's certainly no documented guarantee, and there 
_is_ a case (documented in comments) where the current code may not return 
correctly rounded results on machines that use x87: there's a fast path where 
both numerator and denominator fit into an IEEE 754 double without rounding, 
and we then do a floating-point division.

But we can't hit that case with the proposed code, since the numerator will 
always have at least 55 bits, so the fast path is never taken.

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

Since I've failed to find a coherent statement and proof of the general 
principle I articulated anywhere online, I've included one below. (To be 
absolutely clear, the principle is not new - it's very well known, but oddly 
hard to find written down anywhere.)

--

Setup: introducing jots
===

*Notation.* R is the set of real numbers, Z is the set of integers, operators
like *, / and ^ have their mathematical interpretations, not Python ones.

Fix a precision p > 0 and an IEEE 754 binary floating-point format with
precision p; write F for the set of representable values in that format,
including zeros and infinities. (We don't need NaNs, but feel free to include
them if you want to.)

Let rnd : R -> F be the rounding function corresponding to any of the standard
IEEE 754 rounding modes. We're not ignoring overflow and underflow here: rnd is
assumed to round tiny values to +/-0 and large values to +/-infinity as normal.
(We only really care about round-ties-to-even, but all of the below is
perfectly general.)

*Definition.* For the given fixed precision p, a *jot* is a subinterval of the
positive reals of the form (m 2^e, (m+1) 2^e) for some integers m and e, with
m satisfying 2^p <= m < 2^(p+1).

This is a definition-of-convenience, invented purely for the purposes of this
proof. (And yes, the name is silly. Suggestions for a better name to replace
"jot" are welcome. Naming things is hard.)

We've chosen the size of a jot so that between each consecutive pair a and b of
positive normal floats in F, there are exactly two jots: one spanning from a to
the midpoint (a+b)/2, and another spanning from (a+b)/2 to b. (Since jots are
open, the midpoint itself and the floats a and b don't belong to any jot.)

Now here's the key point: for values that aren't exactly representable and
aren't perfect midpoints, the standard rounding modes, whether directed or
round-to-nearest, only ever care about which side of the midpoint the value to
be rounded lies. In other words:

*Observation.* If x and y belong to the same jot, then rnd(x) = rnd(y).

This is the point of jots: they represent the wiggle-room that we have to
perturb a real number without affecting the way that it rounds under any
of the standard rounding modes.

*Note.* Between any two consecutive *subnormal* values, we have 4 or more
jots, and above the maximum representable float we have infinitely many, but
the observation that rnd is constant on jots remains true at both ends of the
spectrum. Also note that jots, as defined above, don't cover the negative
reals, but we don't need them to for what follows.

Here's a lemma that we'll need shortly.

*Lemma.* Suppose that I is an open interval of the form (m 2^e, (m+1) 2^e)
for some integers m and e satisfying 2^p <= m. Then I is either a jot, or a
subinterval of a jot.

*Proof.* If m < 2^(p+1) then this is immediate from the definition. In
the general case, m satisfies 2^q <= m < 2^(q+1) for some integer q with
p <= q. Write n = floor(m / 2^(q-p)). Then:

n <= m / 2^(q-p) < n + 1, so
n * 2^(q-p) <= m < (n + 1) * 2^(q-p), so
n * 2^(q-p) <= m and m + 1 <= (n + 1) * 2^(q-p)

so

   n * 2^(e+q-p) <= m * 2^e and (m + 1) * 2^e <= (n + 1) * 2^(e+q-p)

So I is a subinterval of (n * 2^(e+q-p), (n+1) * 2^(e+q-p)), which is a jot.


The magic of round-to-odd
=

*Definition.* The function to-odd : R -> Z is defined by:

- to-odd(x) = x if x is an integer
- to-odd(x) = floor(x) if x is not an integer and floor(x) is odd
- to-odd(x) = ceil(x) if x is not an integer and floor(x) is even

*Properties.* Some easy monotonicity properties of to-odd, with proofs left
to the reader:

- If x < 2n for real x and integer n, then to-odd(x) < to-odd(2n)
- If 2n < x for real x and integer n, then to-odd(2n) < to-odd(x)

Here's a restatement of the main principle.

*Proposition.* With p and rnd as in the previous section, suppose that x is a
positive real number and that e is any integer satisfying 2^e <= x. Define a
real number y by:

y = 2^(e-p-1) to-odd(x / 2^(e-p-1))

Then rnd(y) = rnd(x).


Proof of the principle
==

In a nutshell, we show that either

- y = x, or
- x and y belong to the same jot

Either way, since rnd is constant on jots, we get rnd(y) = rnd(x).

Case 1: x = m * 2^(e-p) for some integer m. Then x / 2^(e-p-1) = 2m is
an (even) integer, so to-odd(x / 2^(e-p-1)) = (x / 2^(e-p-1)) and y = x.
Hence rnd(y) = rnd(x).

Case 2: m * 2^(e-p) < x < (m + 1) * 2^(e-p) for some integer m.

Then rearranging, 2m < x / 2^(e-p-1) < 2(m+1). So from the monotonicity
properties of to-odd we have:

   2m < to-odd(x / 2^(e-p-1)) < 2(m+1)

And multiplying through by 2^(e-p-1) we get

   m * 2^(e-p) < y < (m+1) * 2^(e-p).

So both x and y belong to the interval I = (m*2^(e-p), (m+1)*2^(e-p-1)).

Furt

[issue45876] Improve accuracy of stdev functions in statistics

2021-11-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

[Raymond]
> [...] perhaps do an int/int division to match the other code path [...]

Sure, works for me.

--

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



[issue45902] Bytes and bytesarrays can be sorted with a much faster count sort.

2021-11-26 Thread Mark Dickinson

Mark Dickinson  added the comment:

> If there are enough use cases for it.

Well, that's the question. :-) *I* can't think of any good use cases, but maybe 
others can. But if we can't come up with some use cases, then this feels like a 
solution looking for a problem, and that makes it hard to justify both the 
short-term effort and the longer-term maintenance costs of adding the 
complexity.

FWIW, given a need to efficiently compute frequency tables for reasonably long 
byte data, I'd probably reach first for NumPy (and numpy.bincount in 
particular):

Python 3.10.0 (default, Nov 12 2021, 12:32:57) [Clang 12.0.5 
(clang-1205.0.22.11)]
Type 'copyright', 'credits' or 'license' for more information
IPython 7.28.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import collections, numpy as np

In [2]: t = 
b'MDIAIHHPWIRRPFFPFHSPSRLFDQFFGEHLLESDLFSTATSLSPFYLRPPSFLRAPSWIDTGLSEMRLEKDRFSVNLDVKHFSPEELKVKVLGDVIEVHGKHEERQDEHGFISREFHRKYRI
   ...: PADVDPLAITSSLSSDGVLTVNGPRKQVSGPERTIPITREEKPAVAAAPKK';  t *= 100

In [3]: %timeit np.bincount(np.frombuffer(t, np.uint8))
32.7 µs ± 3.15 µs per loop (mean ± std. dev. of 7 runs, 1 loops each)

In [4]: %timeit collections.Counter(t)
702 µs ± 25.8 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [5]: %timeit sorted(t)
896 µs ± 64.2 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

--

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



[issue45902] Bytes and bytesarrays can be sorted with a much faster count sort.

2021-11-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

(Changing the issue type: as I understand it, this is a proposal for a new 
feature, namely new methods bytes.sort and bytearray.sort, rather than a 
performance improvement to an existing feature.)

--
type: performance -> enhancement

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



[issue45902] Bytes and bytesarrays can be sorted with a much faster count sort.

2021-11-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

Can you give example use-cases for sorting a bytes or bytearray object? I see 
value in the intermediate object - the frequency table, but the reconstructed 
sorted bytes object just seems like an inefficient representation of the 
frequency table, and I'm not sure how it would be useful.

As the wikipedia page for counting sort says, the real value is in sorting 
items by keys that are small integers, and the special case where the item is 
identical to the key isn't all that useful:

> In some descriptions of counting sort, the input to be sorted is assumed to 
> be more simply a sequence of integers itself, but this simplification does 
> not accommodate many applications of counting sort.

--
nosy: +mark.dickinson

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

Related: 
https://stackoverflow.com/questions/32150888/should-ldexp-round-correctly

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-25 Thread Mark Dickinson


Mark Dickinson  added the comment:

There's also a potential double-rounding issue with ldexp, when the first 
argument is an int: ldexp(n, e) will first round n to a float, and then (again 
for results in the subnormal range) potentially also need to round the result.

>>> n = 2**53 + 1
>>> e = -1128
>>> math.ldexp(n, e)
0.0
>>> n / (1 << -e)
5e-324

I'm a bit (but only a bit) surprised and disappointed by the Windows issue; 
thanks, Tim. It seems to be okay on Mac (Intel, macOS 11.6.1):

>>> import math
>>> d = math.nextafter(0.0, 1.0)
>>> d
5e-324
>>> d3 = 7 * d
>>> d3
3.5e-323
>>> d3 / 4.0
1e-323
>>> math.ldexp(d3, -2)
1e-323

--

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



[issue45899] NameError on if clause of class-level list comprehension

2021-11-25 Thread Mark Dickinson

Mark Dickinson  added the comment:

This is expected behaviour. See the docs here: 
https://docs.python.org/3.9/reference/executionmodel.html#resolution-of-names

> The scope of names defined in a class block is limited to the class block; it 
> does not extend to the code blocks of methods – this includes comprehensions 
> and generator expressions since they are implemented using a function scope.

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

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-24 Thread Mark Dickinson


Mark Dickinson  added the comment:

Here's a reference for this use of round-to-odd: 
https://www.lri.fr/~melquion/doc/05-imacs17_1-expose.pdf

I'm happy to provide any proofs that anyone feels are needed.

--

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



[issue43475] Worst-case behaviour of hash collision with float NaN

2021-11-24 Thread Mark Dickinson


Mark Dickinson  added the comment:

Just for fun: I gave a somewhat ranty 10-minute talk on this topic at a 
(virtual) conference a few months ago: 
https://www.youtube.com/watch?v=01oeosRVwgY

--

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



[issue43475] Worst-case behaviour of hash collision with float NaN

2021-11-24 Thread Mark Dickinson


Mark Dickinson  added the comment:

@cwg: Yep, we're aware of this. There are no good solutions here - only a mass 
of constraints, compromises and trade-offs. I think we're already somewhere on 
the Pareto boundary of the "best we can do" given the constraints. Moving to 
another point on the boundary doesn't seem worth the code churn.

What concrete action would you propose that the Python core devs take at this 
point?

> it was possible to convert a tuple of floats into a numpy array and back into 
> a tuple, and the hash values of both tuples would be equal.  This is no 
> longer the case.

Sure, but the problem isn't really with hash; that's just a detail. It lies 
deeper than that - it's with containment itself:

>>> import numpy as np
>>> import math
>>> x = math.nan
>>> some_list = [1.5, 2.3, x]
>>> x in some_list
True
>>> x in list(np.array(some_list))  # expect True, get False
False

The result of the change linked to this PR is that the hash now also reflects 
that containment depends on object identity, not just object value. Reverting 
the change would solve the superficial hash problem, but not the underlying 
containment problem, and would re-introduce the performance issue that was 
fixed here.

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-24 Thread Mark Dickinson

Mark Dickinson  added the comment:

> am still studying the new one

Sorry - I should have added at least _some_ comments to it.

Here's the underlying principle, which I think of as "The magic of 
round-to-odd":

Suppose x is a positive real number and e is an integer satisfying 2^e <= x. 
Then assuming IEEE 754 binary64 floating-point format, the quantity:

2^(e-54) * to-odd(x / 2^(e-54))

rounds to the same value as x does under _any_ of the standard IEEE 754 
rounding modes, including the round-ties-to-even rounding mode that we care 
about here.

Here, to-odd is the function R -> Z that maps each integer to itself, but maps 
each non-integral real number x to the *odd* integer nearest x. (So for example 
all of 2.1, 2.3, 2.9, 3.0, 3.1, 3.9 map to 3.)

This works because (x / 2^(e-54)) gives us an integer with at least 55 bits: 
the 53 bits we'll need in the eventual significand, a rounding bit, and then 
the to-odd supplies a "sticky" bit that records inexactness. Note that the 
principle works in the subnormal range too - no additional tricks are needed 
for that. In that case we just end up wastefully computing a few more bits than 
we actually _need_ to determine the correctly-rounded value.

The code applies this principle to the case x = sqrt(n/m) and
e = (n.bit_length() - m.bit_length() - 1)//2. The condition 2^e <= x holds 
because:

2^(n.bit_length() - 1) <= n
m < 2^m.bit_length()
 
so

2^(n.bit_length() - 1 - m.bit_length()) < n/m

and taking square roots gives

2^((n.bit_length() - 1 - m.bit_length())/2) < √(n/m)

so taking e = (n.bit_length() - 1 - m.bit_length())//2, we have

2^e <= 2^((n.bit_length() - 1 - m.bit_length())/2) < √(n/m)

Now putting q = e - 54, we need to compute

2^q * round-to-odd(√(n/m) / 2^q)

rounded to a float. The two branches both do this computation, by moving 2^q 
into either the numerator or denominator of the fraction as appropriate 
depending on the sign of q.

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

Hmm. isqrt_frac_rto is unnecessarily complicated. Here's a more streamlined 
version of the code.


import math

def isqrt_frac_rto(n, m):
"""
Square root of n/m, rounded to the nearest integer using round-to-odd.
"""
a = math.isqrt(n*m) // m
return a | (a*a*m != n)

def sqrt_frac(n, m):
"""
Square root of n/m as a float, correctly rounded.
"""
q = (n.bit_length() - m.bit_length() - 109) // 2
if q >= 0:
return float(isqrt_frac_rto(n, m << 2 * q) << q)
else:
return isqrt_frac_rto(n << -2 * q, m) / (1 << -q)

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Should the last line of sqrt_frac() be wrapped with float()?

It's already a float - it's the result of an int / int division.

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

Here's the float-and-Fraction-based code that I'm using to compare the 
integer-based code against:

def sqrt_frac2(n, m):
"""
Square root of n/m as a float, correctly rounded.
"""
f = fractions.Fraction(n, m)

# First approximation.
x = math.sqrt(n / m)

# Use the approximation to find a pair of floats bracketing the actual sqrt
if fractions.Fraction(x)**2 >= f:
x_lo, x_hi = math.nextafter(x, 0.0), x
else:
x_lo, x_hi = x, math.nextafter(x, math.inf)

# Check the bracketing. If math.sqrt is correctly rounded (as it will be on 
a
# typical machine), then the assert can't fail. But we can't rely on 
math.sqrt being
# correctly rounded in general, so would need some fallback.
fx_lo, fx_hi = fractions.Fraction(x_lo), fractions.Fraction(x_hi)
assert fx_lo**2 <= f <= fx_hi**2

# Compare true square root with the value halfway between the two floats.
mid = (fx_lo + fx_hi) / 2
if mid**2 < f:
return x_hi
elif mid**2 > f:
return x_lo
else:
# Tricky case: mid**2 == f, so we need to choose the "even" endpoint.
# Cheap trick: the addition in 0.5 * (x_lo + x_hi) will round to even.
return 0.5 * (x_lo + x_hi)

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Does the technique you had in mind involve testing 1 ulp up or down to see 
> whether its square is closer to the input?

Kinda sorta. Below is some code: it's essentially just pure integer operations, 
with a last minute conversion to float (implicit in the division in the case of 
the second branch). And it would need to be better tested, documented, and 
double-checked to be viable.


def isqrt_rto(n):
"""
Square root of n, rounded to the nearest integer using round-to-odd.
"""
a = math.isqrt(n)
return a | (a*a != n)


def isqrt_frac_rto(n, m):
"""
Square root of n/m, rounded to the nearest integer using round-to-odd.
"""
quotient, remainder = divmod(isqrt_rto(4*n*m), 2*m)
return quotient | bool(remainder)


def sqrt_frac(n, m):
"""
Square root of n/m as a float, correctly rounded.
"""
quantum = (n.bit_length() - m.bit_length() - 1) // 2 - 54
if quantum >= 0:
return float(isqrt_frac_rto(n, m << 2 * quantum) << quantum)
else:
return isqrt_frac_rto(n << -2 * quantum, m) / (1 << -quantum)

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

> we've run the ball almost the full length of the field and then failed to put 
> the ball over the goal line

But if we only go from "faithfully rounded" to "almost always correctly 
rounded", it seems to me that we're still a couple of millimetres away from 
that goal line. It wouldn't be hard to go for _always_ correctly rounded and 
actually get it over.

> Yes, the Emin and Emax for the default context is already almost big enough

I'm confused: big enough for what? I was thinking of the use-case where the 
inputs are all floats, in which case an Emax of 999 and an Emin of -999 would 
already be more than big enough.

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

One thought: would the deci_sqrt approach help with value ranges where the 
values are well within float limits, but the squares of the values are not? 
E.g., on my machine, I currently get errors for both of the following:

>>> xs = [random.normalvariate(0.0, 1e200) for _ in range(10**6)]
>>> statistics.stdev(xs)

>>> xs = [random.normalvariate(0.0, 1e-200) for _ in range(10**6)]
>>> statistics.stdev(xs)

It's hard to imagine that there are too many use-cases for values of this size, 
but it still feels a bit odd to be constrained to only half of the dynamic 
range of float.

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-23 Thread Mark Dickinson

Mark Dickinson  added the comment:

I'm not sure this is worth worrying about. We already have a very tight error 
bound on the result: if `x` is a (positive) fraction and `y` is the closest 
float to x, (and assuming IEEE 754 binary64, round-ties-to-even, no overflow or 
underflow, etc.) then `math.sqrt(y)` will be in error by strictly less than 1 
ulp from the true value √x, so we're already faithfully rounded. (And in 
particular, if the std. dev. is exactly representable as a float, this 
guarantees that we'll get that standard deviation exactly.)

--

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



[issue45876] Improve accuracy of stdev functions in statistics

2021-11-23 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

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



[issue32582] chr raises OverflowError

2021-11-22 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

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



[issue45862] Anomaly of eval() of list comprehension

2021-11-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

True: there's another detail here that's needed to explain the behaviour. The 
first "for" clause in a list comprehension is special: it's evaluated in the 
enclosing scope, rather than in the local function scope that the list 
comprehension creates. See the docs here: 
https://docs.python.org/3.9/reference/expressions.html?highlight=list%20comprehension#displays-for-lists-sets-and-dictionaries

--

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



[issue45862] Anomaly of eval() of list comprehension

2021-11-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

See also #41216

--

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



[issue45862] Anomaly of eval() of list comprehension

2021-11-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

Thanks for the report. The behaviour is by design: see #5242 (especially 
msg81898) for an explanation.

Closing this issue as a duplicate of #5242.

--
nosy: +mark.dickinson
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> eval() function in List Comprehension doesn't work

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



[issue45784] spam

2021-11-11 Thread Mark Dickinson


Change by Mark Dickinson :


--
title: SAP HANA Training in Chennai -> spam

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



[issue45784] SAP HANA Training in Chennai

2021-11-11 Thread Mark Dickinson


Change by Mark Dickinson :


--
Removed message: https://bugs.python.org/msg406152

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



[issue45776] abc submodule not an attribute of collections on Python 3.10.0 on Windows

2021-11-10 Thread Mark Dickinson


Mark Dickinson  added the comment:

On Mac, collections.abc is imported at startup time via site.py (which imports 
rlcompleter, which imports inspect, which imports collections.abc). I'd guess 
it's the same on Linux.

mdickinson@mirzakhani cpython % ./python.exe
Python 3.11.0a2+ (heads/main:76d14fac72, Nov 10 2021, 15:43:54) [Clang 13.0.0 
(clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; "collections.abc" in sys.modules
True
>>> ^D
mdickinson@mirzakhani cpython % ./python.exe -S
Python 3.11.0a2+ (heads/main:76d14fac72, Nov 10 2021, 15:43:54) [Clang 13.0.0 
(clang-1300.0.29.3)] on darwin
>>> import sys; "collections.abc" in sys.modules
False
>>> ^D

--
nosy: +mark.dickinson

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



[issue45689] Add the ability to give custom names to threads created by ThreadPoolExecutor

2021-11-09 Thread Mark Dickinson


Mark Dickinson  added the comment:

Sorry Rahul: I'm not the right person to help you push this forward.

I'm sympathetic to the problem: I've encountered similar issues in "Real Code", 
where we needed to associate log outputs generated by worker pool threads with 
the actual tasks that generated those logs. But I'm not convinced either that 
setting the thread name is the right mechanism to get that association (it 
doesn't extend nicely to other executor types, for example), or that the API 
you propose is the right one (I find the duplication between `submit` and 
`submit_with_name` to be a bit much).

I'm wondering whether there's some way that executors could use contextvars to 
provide a per-task context. Then a task "name" could potentially be part of 
that context, and possibly you could write a custom log handler that read the 
name from the context when emitting log messages.

If you want to find someone to help push this forward, it may be worth posting 
on the python-ideas mailing list to get discussion going.

--

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



[issue45689] Add the ability to give custom names to threads created by ThreadPoolExecutor

2021-11-08 Thread Mark Dickinson


Mark Dickinson  added the comment:

> previously one could write .submit(function_name, *args, **kwargs)
> but now one should write 
> .submit(function_name, name_of_thread, *args, **kwargs)
> name_of_thread can be None

This approach can't work, I'm afraid: it would be a backwards-incompatible 
change to the `submit` method signature, and would break many existing uses of 
submit.

--
nosy: +mark.dickinson

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



[issue45739] The Python implementation of Decimal does not support the "N" format

2021-11-07 Thread Mark Dickinson


Mark Dickinson  added the comment:

Interesting. I think the behaviour of the Python implementation behaviour is 
actually more correct here: neither `int` nor `float` supports 'N', and I'm not 
seeing any indication in tests or documentation that 'N' should be supported. 
So is this a bug in libmpdec, or a missing feature in the Python 
implementation? (Either way, it's definitely a bug that the two aren't aligned.)

>>> format(123, 'n')
'123'
>>> format(123, 'N')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Unknown format code 'N' for object of type 'int'

--
nosy: +eric.smith

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



[issue45708] PEP 515-style formatting with underscores does not seem to work for Decimal

2021-11-07 Thread Mark Dickinson


Mark Dickinson  added the comment:

Christian Heimes pointed out in the PR discussion that we can't simply modify 
libmpdec, since some vendors unbundle the mpdecimal library.

So some options are:

0. Do nothing.
1. Request that this feature to be added upstream, so that it eventually makes 
its way into core Python.
2. Bypass mpd_parse_fmt_str and do our own format string parsing in _decimal.c 
(e.g., by copying and adapting the code in mpdecimal).
3. Wrap mpd_parse_fmt_str and do our own pre- and post- processing in 
_decimal.c (pre-process to convert "_" to "," in the format string, then 
post-process the formatted string to convert "," back to "_").

Option 2 makes sense to me from the point of view of separation of concerns: 
libmpdec aims to implement Cowlishaw's specification, and formatting lies 
outside of that specification. The decimal specification is pretty much set in 
stone, but the formatting mini-language could change again in the future, and 
when that happens we should be able to update the CPython code accordingly. 
(This brings to mind Robert Martin's Single Responsibility Principle: "Gather 
together those things that change for the same reason, and separate those 
things that change for different reasons.") 

I've updated the PR (and turned it into a draft) to show what option 2 looks 
like. The duplication is a little ugly.

--
nosy: +christian.heimes

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



[issue45392] docstring of "type" could use an update

2021-11-06 Thread Mark Dickinson


Change by Mark Dickinson :


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

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



[issue45708] PEP 515-style formatting with underscores does not seem to work for Decimal

2021-11-06 Thread Mark Dickinson


Mark Dickinson  added the comment:

> It looks like quite similar changes have already been made: 

Yes, I think this isn't something that needs to be resolved for this issue, but 
it is something we need to think about. (Though perhaps the resolution is just 
"Don't worry about it until we need to.")

> I will send a PR, so we can see what exactly it touches / changes.

Ah, sorry; I already made one before reading your message. I'd be happy to get 
your input on that PR, though. (Or to review a PR from you.)

--

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



[issue45708] PEP 515-style formatting with underscores does not seem to work for Decimal

2021-11-06 Thread Mark Dickinson


Change by Mark Dickinson :


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

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



[issue45708] PEP 515-style formatting with underscores does not seem to work for Decimal

2021-11-06 Thread Mark Dickinson


Mark Dickinson  added the comment:

Serhiy: this is not a duplicate of #43624. That issue is about underscores in 
the *fractional* part of a (float / complex / Decimal) number, and the changes 
to the formatting mini-language syntax that would be necessary to support that. 
This issue is simply about bringing Decimal into line with int and float and 
allowing inclusion of underscores in the *integral* part of the formatted 
result.

Raymond: the "General Decimal Arithmetic" specification that the decimal module 
is based on isn't relevant here. It has nothing to say on the subject of 
formatting. We moved beyond the specification the moment we allowed 
`format(some_decimal, 'f')`, let alone `format(some_decimal, '.3f')` or 
`format(some_decimal, ',')`.

As Sander Bollen noted, we've already added ","-form thousands separators to 
Decimal formatting. I can't see any good reason for supporting "," but not 
supporting "_" as a thousands separator for Decimal.

--
nosy: +mark.dickinson

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



[issue45708] PEP 515-style formatting with underscores does not seem to work for Decimal

2021-11-05 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy:  -mark.dickinson

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



[issue45708] PEP 515-style formatting with underscores does not seem to work for Decimal

2021-11-04 Thread Mark Dickinson


Mark Dickinson  added the comment:

> whether Decimal should extend beyond the specification in this case

We already go way beyond the original specification for string formatting. The 
spec doesn't go further than specifying to-scientific-string and 
to-engineering-string, neither of which even get into limiting precision.

--

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



[issue45708] PEP 515-style formatting with underscores does not seem to work for Decimal

2021-11-04 Thread Mark Dickinson


Mark Dickinson  added the comment:

I think the two main reasons that applied to not implementing the parsing part 
of PEP 515 for the Decimal type (speed, compliance with the IBM specification) 
don't apply to the formatting side.

We do need to think about the implications of making local changes to our copy 
of the externally-maintained libmpdec library, though.

Changing Python versions: this is a new feature, so could only go into Python 
3.11.

--
type:  -> enhancement
versions: +Python 3.11 -Python 3.10, Python 3.8, Python 3.9

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



[issue45708] PEP 515-style formatting with underscores does not seem to work for Decimal

2021-11-04 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +eric.smith, mark.dickinson

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



[issue45702] Python/dtoa.c requires 53 bit hardware rounding unavalable on x64

2021-11-03 Thread Mark Dickinson


Mark Dickinson  added the comment:

I'm not sure I understand the problem that you're reporting - what issues are 
you seeing in practice?

x64 should be fine here. In normal circumstances, the compiled version of 
dtoa.c will be using SSE2 instructions and will already be doing floating-point 
arithmetic at 53-bit precision (not 56-bit), following IEEE 754. It's mainly 
the ancient x86/x87 hardware that's problematic. This code has been working 
well on many different x64 platforms for around a decade now.

Can you describe the issue that you're seeing in more detail?

--

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



[issue45555] Object stays alive for weak reference if an exception happens in constructor

2021-10-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

I don't think this is a bug: there's still a reference to the `A` instance in 
`sys.exc_info()` (specifically, in the exception traceback) in this case, so 
that instance is still alive.

If you add an `except: pass` clause to your `try / finally`, you should see 
that dereferencing the weakref gives `None` in the `finally` clause.

--
nosy: +mark.dickinson

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



[issue45569] Drop support for 15-bit PyLong digits?

2021-10-22 Thread Mark Dickinson


New submission from Mark Dickinson :

Looking at issue #35037 (which is a compatibility issue having to do with 
PYLONG_BITS_IN_DIGIT), I'm wondering whether it would make sense to drop 
support for 15-bit PyLong digits altogether. This would simplify some of the 
code, eliminate a configuration option, and eliminate the scope for ABI 
mismatches like that occurring in #35037.

There were a couple of reasons that we kept support for 15-bit digits when 
30-bit digits were introduced, back in #4258.

- At the time, we wanted to use `long long` for the `twodigits` type with 
30-bit digits, and we couldn't guarantee that all platforms we cared about 
would have `long long` or another 64-bit integer type available.

- It wasn't clear whether there were systems where using 30-bit digits in place 
of 15-bit digits might cause a performance regression.

Now that we can safely rely on C99 support on all platforms we care about, the 
existence of a 64-bit integer type isn't an issue (and indeed, we already rely 
on the existence of such a type in dtoa.c and elsewhere in the codebase).

As to performance, I doubt that there are still platforms where using 15-bit 
digits gives a performance advantage, but I admit I haven't checked.

--
messages: 404746
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Drop support for 15-bit PyLong digits?

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



[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

2021-10-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

This should probably be a separate issue, but I wonder whether the 15-bit digit 
option has value any more. Should we just drop that option and always use 
30-bit digits? 

30-bit digits were introduced at a time when we couldn't rely on a 64-bit 
integer type always being available,  so we still needed to keep the 15-bit 
fallback option. But I think that's no longer the case.

--

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



[issue15996] pow() for complex numbers is rough around the edges

2021-10-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

See also discussion in #44970, which is closed as a duplicate of this issue.

--

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



[issue44970] Re-examine complex pow special case handling

2021-10-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Is not it a duplicate of issue15996?

Yes, I think it's close enough. Thanks.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> pow() for complex numbers is rough around the edges

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



[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

2021-10-19 Thread Mark Dickinson


Mark Dickinson  added the comment:

> Closing this as out of date.

SGTM. Thanks.

--

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



[issue45476] [C API] Convert "AS" functions, like PyFloat_AS_DOUBLE(), to static inline functions

2021-10-15 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

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



[issue45412] [C API] Remove Py_OVERFLOWED(), Py_SET_ERRNO_ON_MATH_ERROR(), Py_ADJUST_ERANGE1()

2021-10-11 Thread Mark Dickinson


Mark Dickinson  added the comment:

+1 for the removals. (We should fix #44970 too, but as you say that's a 
separate issue. And I suspect that the Py_ADJUST_ERANGE1() use for float pow 
should be replaced, too.)

--

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



[issue45392] docstring of "type" could use an update

2021-10-06 Thread Mark Dickinson


Mark Dickinson  added the comment:

Larry: the first line was introduced in #20189. Does it still make sense to 
keep it at this point?

--
nosy: +larry

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



[issue45392] docstring of "type" could use an update

2021-10-06 Thread Mark Dickinson


New submission from Mark Dickinson :

The docstring of the "type" builtin is mildly confusing. Here's what the first 
few lines of the output for `help(type)` look like for me (on Python 3.10.0rc2):

class type(object)
 |  type(object_or_name, bases, dict)
 |  type(object) -> the object's type
 |  type(name, bases, dict) -> a new type

The first line there seems redundant, and potentially misleading, since it 
suggests that `type(object, bases, dict)` might be legal.

The third line is missing mention of possible keyword arguments.

--
messages: 403302
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: docstring of "type" could use an update

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



[issue45333] += operator and accessors bug?

2021-09-30 Thread Mark Dickinson


Mark Dickinson  added the comment:

Did you by any chance get an error message resembling the following?

> "Cannot cast ufunc 'add' output from dtype('float64') to dtype('int64') with 
> casting rule 'same_kind'"

(If you can give us a complete piece of code that we can run ourselves, that 
would save us from having to guess what the issue is.)

--
nosy: +mark.dickinson

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



[issue45332] Decimal test and benchmark are broken

2021-09-30 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

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



[issue36841] Supporting customization of float encoding in JSON

2021-09-30 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy: +mark.dickinson

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



[issue45318] Python 3.10: cyclomatic complexity of match-case syntax

2021-09-29 Thread Mark Dickinson

Mark Dickinson  added the comment:

@Boštjan Mejak: I think this question belongs on a discussion forum rather than 
in the Python bug tracker - as I understand it, there's no bug reported here, 
and no change to the Python core proposed.

I'll close here. You might consider taking this to discuss.python.org or 
another forum.

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

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



[issue44019] operator.call/operator.__call__

2021-09-24 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset bfe26bbad787c124f0ce144cff1b513ef9d2dc9c by Terry Jan Reedy in 
branch 'main':
bpo-44019: Add missing comma to operator.call doc (GH-28551)
https://github.com/python/cpython/commit/bfe26bbad787c124f0ce144cff1b513ef9d2dc9c


--

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



[issue44019] operator.call/operator.__call__

2021-09-24 Thread Mark Dickinson


Mark Dickinson  added the comment:

Thanks for the contribution!

--
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

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



[issue44019] operator.call/operator.__call__

2021-09-24 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 6587fc60d447603fb8c631d81d9bb379f53c39ab by Antony Lee in branch 
'main':
bpo-44019: Implement operator.call(). (GH-27888)
https://github.com/python/cpython/commit/6587fc60d447603fb8c631d81d9bb379f53c39ab


--

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



[issue45218] cmath.log has an invalid signature

2021-09-16 Thread Mark Dickinson


Mark Dickinson  added the comment:

> and `log` base `math.e` is likely to be less accurate than plain natural log

Nope, that's nonsense, since the two-argument form simply divides by log(base), 
and while log(math.e) is mathematically not exactly 1 (its exact value, 
assuming IEEE 754 binary64, starts 0.468176229339410862948..., 
which is off from 1.0 by around 0.48 ulps), it's *just* close enough that with 
a well-behaved libm log implementation it's exactly 1.0 after rounding.

I still don't like the idea of math.e as a default value here, but I'd have to 
work harder to identify why it makes me uneasy.

--

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



[issue45218] cmath.log has an invalid signature

2021-09-16 Thread Mark Dickinson


Mark Dickinson  added the comment:

See also #36306 and #29299. There may be nothing to be done here, but it would 
be nice if math.log and cmath.log at least behaved in the same way. A default 
of `None` doesn't seem like a terrible option.

(BTW, just to forestall the suggestion, a default of `math.e` or `cmath.e` is 
definitely *not* the right thing to use as a default: `math.e` is not exactly 
Euler's value for e, and `log` base `math.e` is likely to be less accurate than 
plain natural log.)

--

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



[issue45218] cmath.log has an invalid signature

2021-09-16 Thread Mark Dickinson


Mark Dickinson  added the comment:

Issue #43067 is similar. I'm not sure what the best solution is in this case:

- un-argument-clinic cmath.log, and document the signature using two lines 
(similar to range):

 log(z)
 log(z, base)

- change the behaviour of cmath.log so that the second argument is allowed be 
None (and defaults to None)

--

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



[issue45218] cmath.log has an invalid signature

2021-09-16 Thread Mark Dickinson


Change by Mark Dickinson :


--
type:  -> behavior

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



[issue45218] cmath.log has an invalid signature

2021-09-16 Thread Mark Dickinson


New submission from Mark Dickinson :

inspect.signature reports that the cmath.log function has an invalid signature:

Python 3.11.0a0 (heads/fix-44954:d0ea569eb5, Aug 19 2021, 14:59:04) [Clang 
12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> import inspect
>>> inspect.signature(cmath.log)
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 3215, in 
signature
return Signature.from_callable(obj, follow_wrapped=follow_wrapped,
   ^^^
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 2963, in 
from_callable
return _signature_from_callable(obj, sigcls=cls,
   ^
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 2432, in 
_signature_from_callable
return _signature_from_builtin(sigcls, obj,
   
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 2244, in 
_signature_from_builtin
return _signature_fromstr(cls, func, s, skip_bound_arg)
   
  File "/Users/mdickinson/Python/cpython/Lib/inspect.py", line 2114, in 
_signature_fromstr
raise ValueError("{!r} builtin has invalid signature".format(obj))
^^
ValueError:  builtin has invalid signature

--
components: Extension Modules
messages: 401933
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: cmath.log has an invalid signature
versions: Python 3.10, Python 3.11, Python 3.9

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-10 Thread Mark Dickinson


Mark Dickinson  added the comment:

I'd also really like to avoid a system-dependent default. The danger is that 
code of the form

some_externally_supplied_integer.to_bytes(length=4)

can be written and thoroughly tested, only to fail unexpectedly some time later 
when that code happens to meet a big-endian machine. In most real-world cases 
with input length >= 1, it's unlikely that the system byteorder is the right 
thing, especially for from_bytes: what you need to know is what endianness the 
integer was encoded with, and that's not likely to be well correlated with the 
endianness that the machine you're running on right now happens to be using. 
(The choice of default obviously doesn't matter in cases where you're encoding 
and decoding on the same system, but there are going to be plenty of cases 
where that's not true.)

This is essentially the same issue that PEP 597 starts to address with 
`open(filename)` with no encoding specified. That system-specific default 
encoding has caused us real issues in production code.

--
nosy: +mark.dickinson

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



[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

2021-09-09 Thread Mark Dickinson


Mark Dickinson  added the comment:

@Erik: Do you have a moment to look at the PR (GH-27853) and see if the 
proposed changes work for you?

--

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



[issue45034] Improve struct.pack out of range error messages

2021-09-07 Thread Mark Dickinson


Mark Dickinson  added the comment:

The out-of-range error messages for unsigned short and short have been fixed, 
thanks to Nikita Sobolev. They resulted from a rather odd use of the 
Py_STRINGIFY macro, which meant that not only were the messages obscure, but 
they differed from system to system: e.g., on my machine I get: "struct.error: 
ushort format requires 0 <= number <= (32767 *2 +1)", and "struct.error: short 
format requires (-32767 -1) <= number <= 32767", complete with the weird 
spacing.

There's still room for normalising the other messages and/or converting the 
limits to hex if anyone wants to provide a PR.

I'm unsure about using hex universally: while `0x` (or even 
better, `0x___`) is definitely more useful than 
`18446744073709551615`, I think I'd still find `-128` more immediately readable 
than `-0x80`.

--

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



[issue45034] Improve struct.pack out of range error messages

2021-09-07 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 8ca6b61e3fd7f1e2876126cee82da8d812c8462f by Nikita Sobolev in 
branch 'main':
bpo-45034: Fix how upper limit is formatted for `struct.pack("H", ...)` 
(GH-28178)
https://github.com/python/cpython/commit/8ca6b61e3fd7f1e2876126cee82da8d812c8462f


--

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



[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

2021-08-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

All done, I think. Closing.

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

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



[issue14613] time.time can return NaN

2021-08-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

> I propose we close it [...]

Seconded!

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

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



[issue39218] Assertion failure when calling statistics.variance() on a float32 Numpy array

2021-08-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

> what it's correcting for is an inaccurate value of "c" [...]

In more detail:

Suppose "m" is the true mean of the x in data, but all we have is an 
approximate mean "c" to work with. Write "e" for the error in that 
approximation, so that c = m + e. Then (using Python notation, but treating the 
expressions as exact mathematical expressions computed in the reals):

   sum((x-c)**2 for x in data)

== sum((x-m-e)**2 for x in data)

== sum((x - m)**2 for x in data) - 2 * sum((x - m)*e for x in data)
 + sum(e**2 for x in data)

== sum((x - m)**2 for x in data) - 2 * e * sum((x - m) for x in data)
 + sum(e**2 for x in data)

== sum((x - m)**2 for x in data) + sum(e**2 for x in data)
   (because sum((x - m) for x in data) is 0)

== sum((x - m)**2 for x in data) + n*e**2

So the error in our result arising from the error in computing m is that n*e**2 
term. And that's the term that's being subtracted here, because

   sum(x - c for x in data) ** 2 / n
== sum(x - m - e for x in data) ** 2 / n
== (sum(x - m for x in data) - sum(e for x in data))**2 / n
== (0 - n * e)**2 / n
== n * e**2

--

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



[issue39218] Assertion failure when calling statistics.variance() on a float32 Numpy array

2021-08-26 Thread Mark Dickinson


Mark Dickinson  added the comment:

> The rounding correction in _ss() looks mathematically incorrect to me [...]

I don't think it was intended as a rounding correction - I think it's just 
computing the variance (prior to the division by n or n-1) of the `(x - c)` 
terms using the standard "expectation of x^2 - (expectation of x)^2" formula:

  sum((x - c)**2 for x in data) - (sum(x - c for x in data)**2) / n

So I guess it *can* be thought of as a rounding correction, but what it's 
correcting for is an inaccurate value of "c"; it's not correcting for 
inaccuracies in the subtraction results. That is, if you were to add an 
artificial error into c at some point before computing "total" and "total2", 
that correction term should take you back to something approaching the true sum 
of squares of deviations.

So mathematically, I think it's correct, but not useful, because mathematically 
"total2" will be zero. Numerically, it's probably not helpful.

--

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



[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

2021-08-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

We've got some buildbot failures; GH-27902 should fix them. Apologies for not 
catching this while reviewing GH-27901.

--

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



[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

2021-08-23 Thread Mark Dickinson


Change by Mark Dickinson :


--
pull_requests: +26360
pull_request: https://github.com/python/cpython/pull/27902

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



[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

2021-08-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

> If SupportsComplex and SupportsBytes are just for "has __complex__/__bytes__ 
> method", they are virtually useless.

I agree that "SupportsComplex" isn't directly useful in user-land. I think its 
main value is as a building block in things like `Union[SupportsComplex, 
SupportsFloat, SupportsIndex]`.

For me, the gain from implementing complex.__complex__ is that the test "can be 
used as a complex number" can now be expressed purely in terms of the protocols 
offered, without reference to concrete types.

--

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



[issue44019] operator.call/operator.__call__

2021-08-23 Thread Mark Dickinson


Mark Dickinson  added the comment:

This seems like a reasonable addition to me. Victor: any thoughts?

--
nosy: +mark.dickinson, vstinner

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



[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

2021-08-23 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset 6082bb5addab93755ab6e2bd2ed6021b391e10d1 by Mark Dickinson in 
branch 'main':
bpo-24234: implement complex.__complex__ (GH-27887)
https://github.com/python/cpython/commit/6082bb5addab93755ab6e2bd2ed6021b391e10d1


--

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



[issue44977] Deprecate delegation of int to __trunc__?

2021-08-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

I think the needs are sufficiently different that __trunc__ still has value as 
its own thing, and it's a natural counterpart to __floor__ and __ceil__ (out of 
all the directed rounding modes, rounding towards zero probably turns up more 
often than rounding towards +inf or -inf).

__int__ has the disadvantage that it must return an int, so it's not useful for 
other Python-based numeric systems with their own rational number / integer 
pairing. For example, with gmpy2, truncating an mpq instance returns an mpz 
instance, which is what I'd expect and want - if I'm working with huge values 
then it would be annoying for math.trunc to do the inefficient thing and return 
a plain int.

>>> from gmpy2 import mpq
>>> math.trunc(mpq(22, 7))
mpz(3)

SymPy behaves similarly:

>>> from sympy import Rational
>>> type(math.trunc(Rational(22, 7)))


On the other side, there are conversions to integer that it doesn't make sense 
to think of as truncation. It would be odd for a UUID to be a valid input to 
math.trunc, for example:

>>> int(uuid.uuid4())
43341414945793370480422623795805641537

--

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



[issue44977] Deprecate delegation of int to __trunc__?

2021-08-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

A GitHub code search shows a substantial number of uses of math.trunc out in 
the wild:

https://github.com/search?q=math.trunc+extension%3Apy=Code

So unfortunately, getting rid of math.trunc and __trunc__ looks a bit too much 
as though it would cause gratuitous breakage.

--

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



[issue37082] Assignment expression symbol (walrus) not in built-in help()

2021-08-22 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy:  -mark.dickinson

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



[issue39301] Specification of bitshift on integers should clearly state floor division used

2021-08-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

Closing; I think this is addressed.

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

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



[issue27901] DOC: inspect.ismethod returns different results on the same basic code between Python2.7 Python3.5

2021-08-22 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy:  -mark.dickinson

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



[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

2021-08-22 Thread Mark Dickinson


Change by Mark Dickinson :


--
nosy:  -mark.dickinson

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



[issue32082] atexit module: allow getting/setting list of handlers directly

2021-08-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

Thanks, Irit. Should we close this issue as a duplicate? It's not identical 
(being able to modify the list of handlers versus just being able to inspect 
it), but it's pretty close.

--

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



[issue44978] Argument Clinic should not exclude __complex__ methods

2021-08-22 Thread Mark Dickinson


Change by Mark Dickinson :


--
assignee:  -> mark.dickinson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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



[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

2021-08-22 Thread Mark Dickinson


Change by Mark Dickinson :


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

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



[issue44978] Argument Clinic should not exclude __complex__ methods

2021-08-22 Thread Mark Dickinson


Mark Dickinson  added the comment:


New changeset c5c3fbe2a16a8fcb77eb98eda53efb3e03b863ca by Mark Dickinson in 
branch 'main':
bpo-44978: allow Argument Clinic to handle __complex__ special methods 
(GH-27886)
https://github.com/python/cpython/commit/c5c3fbe2a16a8fcb77eb98eda53efb3e03b863ca


--

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



[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

2021-08-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

> [...] we'll need `int.__complex__` and `float.__complex__` implementations as 
> well as `complex.__complex__`.

The real problem here is that the "typing.SupportsComplex" protocol isn't a 
good match for code that needs to know that a given value `x` can be treated as 
though it were a complex number.

The test that best matches "usable as a complex number" seems to be that 
type(x) implements at least one of `__index__`, `__float__` or `__complex__`, 
or that `x` is a subclass of complex.

It looks to me as though the right thing to do here is to just implement 
complex.__complex__, but not int.__complex__ or float.__complex__.  Then at 
least we can remove the subclass test from the above and express the test 
purely in terms of special methods: __index__, __float__ and __complex__. And 
then perhaps it's for the typing module to find a more convenient way to 
express the union of typing.SupportsIndex, typing.SupportsFloat and 
typing.SupportsComplex.

--

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



[issue24234] Should we define complex.__complex__ and bytes.__bytes__?

2021-08-22 Thread Mark Dickinson


Mark Dickinson  added the comment:

If the goal is to have `isinstance(obj, typing.SupportsComplex)` pass for 
objects that are convertible to complex, then we'll need `int.__complex__` and 
`float.__complex__` implementations as well as `complex.__complex__`.

--

___
Python tracker 
<https://bugs.python.org/issue24234>
___
___
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   >