[issue41598] Adding support for rounding modes to builtin round

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

[issue41598] Adding support for rounding modes to builtin round

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 M

[issue41610] Any Raspberry Pi Zero Projects to try?

Change by Mark Dickinson : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue41610> ___ ___ Python-bugs-list mailing list Unsubscrib

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

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

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

Mark Dickinson added the comment: Whoops. There's a missing `count += 1` in there, of course. -- ___ Python tracker <https://bugs.python.org/issue41458> ___ ___

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

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

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

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

[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)

Change by Mark Dickinson : -- nosy: +tim.peters ___ Python tracker <https://bugs.python.org/issue41487> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

[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)

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

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

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 si

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

Mark Dickinson added the comment: Also related: #40269 -- ___ Python tracker <https://bugs.python.org/issue17336> ___ ___ Python-bugs-list mailing list Unsub

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

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 comp

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

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 s

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

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue41485> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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://bu

[issue36788] Add clamp() function to builtins

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/issue36

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

Change by Mark Dickinson : -- resolution: rejected -> duplicate superseder: -> Add clamp() function to builtins ___ Python tracker <https://bugs.python.org/i

[issue36788] Add clamp() function to builtins

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

[issue41342] Convert int.__round__ to Argument Clinic

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue41342> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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 ___

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

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

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

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

[issue41269] Wrong subtraction calculations

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

[issue41245] cmath module documentation is misleading on branch cuts

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://

[issue41245] cmath module documentation is misleading on branch cuts

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

[issue41245] cmath module documentation is misleading on branch cuts

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/issu

[issue41245] cmath module documentation is misleading on branch cuts

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.pytho

[issue41245] cmath module documentation is misleading on branch cuts

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

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

Mark Dickinson added the comment: @JD-Veiga: would you be willing to work on a PR? -- ___ Python tracker <https://bugs.python.org/issue41205> ___ ___ Python-bug

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

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

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

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 ___ Pytho

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

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

[issue41100] Build failure on macOS 11 (beta)

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue41100> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39699] Some CIs silence potentially useful output from make

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

[issue41090] Support for "Apple Silicon"

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 <

[issue41090] Support for "Apple Silicon"

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

[issue41057] Division error

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

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

Mark Dickinson added the comment: I think #39277 is related. -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue40999> ___ ___ Python-bug

[issue29882] Add an efficient popcount method for integers

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

[issue29882] Add an efficient popcount method for integers

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

[issue29882] Add an efficient popcount method for integers

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

[issue29882] Add an efficient popcount method for integers

Change by Mark Dickinson : -- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.10 -Python 3.7 ___ Python tracker <https://bugs.python.or

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

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.or

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

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

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

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

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

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 w

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

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/issue40

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

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 pr

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

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 widespr

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

Mark Dickinson added the comment: On naming, maybe float.from_number or float.from_numeric? -- ___ Python tracker <https://bugs.python.org/issue40801> ___ ___

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

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 __floa

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

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. S

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

Mark Dickinson added the comment: Proof of concept in GH-20481 -- ___ Python tracker <https://bugs.python.org/issue40801> ___ ___ Python-bugs-list mailin

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

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/issu

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

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

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

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/issu

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

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 s

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

Change by Mark Dickinson : -- versions: -Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue40780> ___ ___ Python-bugs-list mailin

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

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

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

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.int6

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

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

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

Change by Mark Dickinson : -- pull_requests: +19703 pull_request: https://github.com/python/cpython/pull/20449 ___ Python tracker <https://bugs.python.org/issue37

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

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

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

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

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

Mark Dickinson added the comment: The PR is ready for review. -- ___ Python tracker <https://bugs.python.org/issue40780> ___ ___ Python-bugs-list mailin

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

Mark Dickinson added the comment: Created a PR with a tentative fix. It still needs regression tests; working on those. -- ___ Python tracker <https://bugs.python.org/issue40

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

Change by Mark Dickinson : -- keywords: +patch pull_requests: +19692 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20435 ___ Python tracker <https://bugs.python.org/issu

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

Mark Dickinson added the comment: This appears to go all the way down to _Py_dg_dtoa, which in mode 3 is supposed to suppress trailing zeros. I'll dig in and see if I can find a fix. (Assigning to me so that I don't forget it, but I also don't want to block anyone else - if anyone else

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

Mark Dickinson added the comment: Very interesting. Agreed that this looks like a bug. It affects old-style formatting, too: >>> "%.3g" % 1503 '1.5e+03' >>> "%.3g" % 1504 '1.5e+03' >>> "%.3g" % 1505 '1.50e+03' -- v

[issue29882] Add an efficient popcount method for integers

Mark Dickinson added the comment: PR is updated and mergeable. -- ___ Python tracker <https://bugs.python.org/issue29882> ___ ___ Python-bugs-list mailin

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

Mark Dickinson added the comment: Thanks Zackery for the fix! Nick: is this good enough to close, or would you like to see something more here? -- ___ Python tracker <https://bugs.python.org/issue39

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

Mark Dickinson added the comment: New changeset c2a177adf3575d4eb81030fba851f78d7a8e3f51 by Miss Islington (bot) in branch '3.8': bpo-39301: State that floor division is used for right shift operations (GH-20347) (GH-20415) https://github.com/python/cpython/commit

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

Mark Dickinson added the comment: New changeset b068d892c1ba7b996e43aceb974bfadac3c577ed by Miss Islington (bot) in branch '3.7': bpo-39301: State that floor division is used for right shift operations (GH-20347) (GH-20416) https://github.com/python/cpython/commit

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

Mark Dickinson added the comment: New changeset cc0f50d62c75a1d171f5de9b56caef64e79eb013 by Miss Islington (bot) in branch '3.9': bpo-39301: State that floor division is used for right shift operations (GH-20347) (GH-20414) https://github.com/python/cpython/commit

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

Mark Dickinson added the comment: New changeset af7553ac95a96713be847dd45bc5a8aeb0a75955 by Zackery Spytz in branch 'master': bpo-39301: State that floor division is used for right shift operations (GH-20347) https://github.com/python/cpython/commit/af7553ac95a96713be847dd45bc5a8aeb0a75955

[issue29882] Add an efficient popcount method for integers

Mark Dickinson added the comment: > For example, should numpy.int64 get this method as well? That's for the NumPy folks to decide (and I've added Nathaniel Smith to the nosy in case he wants to comment), but I don't see any particularly strong reason that NumPy would need to

[issue29882] Add an efficient popcount method for integers

Mark Dickinson added the comment: I'm re-reviewing this discussion three years on. I'd be happy for this to go into 3.10. Are there other strong opinions? It would be good to either update and merge the PR, or close as rejected. -- ___ Python

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

Change by Mark Dickinson : -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue39301> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40028] Math module method to find prime factors for non-negative int n

Mark Dickinson added the comment: [Rémi Lapeyre] > In the end, if some core devs think that putting together the various > discussions for an imath module in a coherent PEP [...] I can't answer for other core devs. My *guess* is that there's a reasonable chance that a well-writt

[issue37973] improve docstrings of sys.float_info

Mark Dickinson added the comment: PR applied. Thank you! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

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

Mark Dickinson added the comment: > I confess that I've no idea what the "without overflow check" bit means After some digging, it is indeed to do with the int/long unification: - In Python 2.1, arithmetic operations on ints would raise OverflowError on overflow. - Except th

[issue37973] improve docstrings of sys.float_info

Mark Dickinson added the comment: New changeset fdc5a94279736a7715dd35c5354a3c27098d0897 by Zackery Spytz in branch 'master': bpo-37973: Improve the docstrings of sys.float_info (GH-19218) https://github.com/python/cpython/commit/fdc5a94279736a7715dd35c5354a3c27098d0897

[issue40028] Math module method to find prime factors for non-negative int n

Mark Dickinson added the comment: It seems we don't have a champion (someone willing to write a PEP) for this issue. I'm going to close. And if or when we do have such a champion, it probably makes more sense to re-open #37132, which is specifically about adding `imath`, or make a new

[issue40028] Math module method to find prime factors for non-negative int n

Change by Mark Dickinson : -- versions: +Python 3.10 -Python 3.9 ___ Python tracker <https://bugs.python.org/issue40028> ___ ___ Python-bugs-list mailin

[issue40257] Improve the use of __doc__ in pydoc

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue40257> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Mark Dickinson added the comment: Agreed; closing. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

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

Mark Dickinson added the comment: > We could add an option to cause NaNs to raise an error, but I don't think it > would get used. If that option were extended to also cause infinities to raise an error, then I'd use it. We have code that's producing JSON without knowing in advance e

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

Mark Dickinson added the comment: ... but I'm an idiot, since that option is already there (allow_nan=False), and I've just checked that we are in fact using it. -- ___ Python tracker <https://bugs.python.org/issue40

[issue40455] GCC 10 compiler warnings

Change by Mark Dickinson : -- nosy: -mark.dickinson ___ Python tracker <https://bugs.python.org/issue40455> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39657] Bezout and Chinese Remainder Theorem in the Standard Library?

Mark Dickinson added the comment: Related (imath module discussions): #37132, #40028. -- ___ Python tracker <https://bugs.python.org/issue39657> ___ ___ Pytho

[issue40641] Reserved word pair used in lambda tutorial without being noted as a reserved word

Change by Mark Dickinson : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue40641] Reserved word pair used in lambda tutorial without being noted as a reserved word

Mark Dickinson added the comment: `pair` isn't a reserved word here; it's just the formal parameter name. Think of the lambda here as being equivalent to a function def second(pair): return pair[1] You can replace the word "pair" here with any other valid Python

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

Mark Dickinson added the comment: I don't think "null" in JSON is supposed to represent "Not a Number"; it's closer in meaning to Python's `None`. I definitely wouldn't want to see nans translated to "null" by default. This also only seems to address a part of

[issue40028] Math module method to find prime factors for non-negative int n

Mark Dickinson added the comment: @Rémi Lapeyre (since you requested re-opening of the issue :-) Are you interested in putting together a PEP for this? -- ___ Python tracker <https://bugs.python.org/issue40

[issue37986] Improve perfomance of PyLong_FromDouble()

Change by Mark Dickinson : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37986> ___ ___

[issue37986] Improve perfomance of PyLong_FromDouble()

Mark Dickinson added the comment: New changeset 86a93fddf72a2711aca99afa0c5374c8d6b4a321 by Sergey Fedoseev in branch 'master': bpo-37986: Improve perfomance of PyLong_FromDouble() (GH-15611) https://github.com/python/cpython/commit/86a93fddf72a2711aca99afa0c5374c8d6b4a321

[issue37132] Add a module for integer related math functions

Mark Dickinson added the comment: See also #40028 -- ___ Python tracker <https://bugs.python.org/issue37132> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40541] Add optional weights parameter to random.sample()

Mark Dickinson added the comment: +1 for the functionality. How about "counts" instead of "weights"? I found the name "weights" misleading - my first thought was that this would be doing a weighted sampling without replacement (like NumPy's `random.choice(

[issue40541] Add optional weights parameter to random.sample()

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue40541> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    2   3   4   5   6   7   8   9   10   11   >