[issue43255] Ceil division with /// operator

Change by Mark Dickinson : -- resolution: not a bug -> rejected ___ Python tracker <https://bugs.python.org/issue43255> ___ ___ Python-bugs-list mai

[issue43255] Ceil division with /// operator

Mark Dickinson added the comment: I can't recall where I saw this originally, but you can use the spaceship operator "--0--" to turn floor division into ceiling division: >>> 12//5 2 >>> --0-- 12//5 3 There's also the ++0++ operator when you want to emphasiz

[issue41100] Support macOS 11 and Apple Silicon Macs

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

[issue43237] datetime.__eq__ returns true when timezones don't match

Mark Dickinson added the comment: I'm going to close here. While changing the behaviour isn't completely out of the question, it would need (a) a clear proposal on how to deal with order comparisons and backwards compatibility, and (b) strong support from the community. A PEP is probably

[issue43238] python picking garbage values randomly incase running palindrome function

Change by Mark Dickinson : -- stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue43238> ___ ___ Python-bugs-

[issue43237] datetime.__eq__ returns true when timezones don't match

Mark Dickinson added the comment: Hi Richard. Thanks for the report. Python's working as designed (and as documented and tested) here. IOW, the behaviour is deliberate - this isn't a bug. Any change in behaviour would have to target 3.10 at the earliest (and it's already quite late

[issue43238] python picking garbage values randomly incase running palindrome function

Mark Dickinson added the comment: Hi Raghav. I think you think you're found a bug in Python, but I'm afraid it's difficult to tell from your report what you think that bug is. Please state clearly what you did, what you expected to happen (and why), and what actually happened. You may find

[issue39820] Bracketed paste mode for REPL: don't execute pasted command before ENTER is pressed explicitly

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

[issue43134] (list have item) instate (item in list)

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

[issue43180] Lists without commas?

Mark Dickinson added the comment: This is by design. It's not really to do with lists, but to do with placing two string literals next to each other. See: https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation See also https://www.python.org/dev/peps/pep

[issue43177] How to use `long double` as a PyObject?

Mark Dickinson added the comment: I'm setting the Python version to 3.10 here: this is a request for a new feature, and as such it can't go into already-released Python versions. -- versions: +Python 3.10 -Python 3.7 ___ Python tracker <ht

[issue43177] How to use `long double` as a PyObject?

Mark Dickinson added the comment: > Any plans to add it in the future? It depends - it's not really clear to me what you're asking for. If you just want to get a Python `float` from a C long double, then cast to double in the C code and then use `PyFloat_FromDouble`. Obviously that lo

[issue43177] How to use `long double` as a PyObject?

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

[issue43177] How to use `long double` as a PyObject?

Mark Dickinson added the comment: You're correct that there's nothing in the C-API to handle a C `long double`. (Similarly, there's very little for C `float` values.) You've added "ctypes" as a component, but in the message you're talking about the C-API. Can you clarify what yo

[issue43101] Add deprecation of float limits for resource to documentation

Mark Dickinson added the comment: Maybe the better fix is to have better reporting of the `preexec_fn` error, so that it's not entirely hidden by the `SubprocessError`? On the other hand, given that `preexec_fn` may be going away entirely soon (see #38435), that may not be worth

[issue43161] Taking sum of massive list comprehension results in total system crash.

Mark Dickinson added the comment: > 28 bytes for the actual object Gah. I should proof-read before hitting "Submit Changes". That should say "28 bytes for each int object". -- ___ Python tracker <https://

[issue43161] Taking sum of massive list comprehension results in total system crash.

Mark Dickinson added the comment: The list you're attempting to create needs around 41GB of RAM (28 bytes for the actual object, rounded up to 32 bytes per object for alignment reasons, plus 8 bytes for each pointer in the list). Assuming you don't have that much memory on your system

[issue43101] Add deprecation of float limits for resource to documentation

Mark Dickinson added the comment: Agreed with Serhiy that it's not practical to document all the affected functions. -- ___ Python tracker <https://bugs.python.org/issue43

[issue43060] Convert _decimal C API from pointer array to struct

Mark Dickinson added the comment: Can you explain what problem this would be solving? -- ___ Python tracker <https://bugs.python.org/issue43060> ___ ___ Pytho

[issue43134] (list have item) instate (item in list)

Mark Dickinson added the comment: @Masoud: There's a significant cost to introducing new syntax into Python; there need to be really significant benefits to justify that cost. In this case, the benefits are slight, and nowhere near the threshold needed to justify introducing a new keyword

[issue42686] include built-in Math functions in SQLite to 3.35.0 of march 2021

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

[issue43147] Remove mention of "subcontrary mean" from the docs

Mark Dickinson added the comment: Sounds good to me. I don't recall ever meeting the term. -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue43

[issue43116] Integer division numerical error

Mark Dickinson added the comment: Python's `//` operator does floor division: that is, the (true) quotient is converted to an integer by taking the floor (rounding towards -infinity) instead of truncating (rounding towards zero). So indeed it's not a bug. The behaviour is documented here

[issue43053] Speed up math.isqrt, again

Change by Mark Dickinson : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue43100] Python fails to execute shiv pyz files greater than 2 GB

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

[issue43100] Python fails to execute shiv pyz files greater than 2 GB

Mark Dickinson added the comment: This sounds as though it should be reported to the Shiv maintainers. (This tracker is for core Python, and Shiv isn't part of core Python.) If the Shiv problem turns out to be due to an underlying core Python bug, this issue can be re-opened with more

[issue43088] Regression in math.hypot

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

[issue42911] Addition chains for pow saves 5-20% time for pow(int, int)

Mark Dickinson added the comment: Looks like Tim isn't taking the bait. :-) @Jurjen: Thank you for the suggestion and PR, but I'm going to close here; for me this ends up on the wrong side of the performance / complexity trade-off. -- resolution: -> rejected stage: patch rev

[issue43053] Speed up math.isqrt, again

Mark Dickinson added the comment: > Java's implementation of BigInteger.sqrt can't do that. :-) Well, okay, depending on your definition of "a few", actually it can, but Python is still faster. -- ___ Python tracker <https:/

[issue43053] Speed up math.isqrt, again

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

[issue43053] Speed up math.isqrt, again

Mark Dickinson added the comment: > the complication probably amounts to no more than 10-20 extra lines of C code A net difference of 16 lines of code, as it turns out. The branch is here: https://github.com/mdickinson/cpython/tree/isqrt-performance Informal not-very-scientific timings m

[issue43062] Non-integer values in collections.Counter

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

[issue43057] Timezone 'Etc/GMT-5' functions as Timezone 'Etc/GMT+5'

Mark Dickinson added the comment: This isn't a Python bug - it's a quirk of the way that the "Etc/***" timezones are defined. See for example https://en.wikipedia.org/wiki/Tz_database#Area: > In order to conform with the POSIX style, those zone names beginning with >

[issue43053] Speed up math.isqrt, again

Mark Dickinson added the comment: Translation of the proposal to the iterative version described here: https://github.com/python/cpython/blob/64fc105b2d2faaeadd1026d2417b83915af6622f/Modules/mathmodule.c#L1591-L1611 The main loop: c = (n.bit_length() - 1) // 2 a = 1

[issue43053] Speed up math.isqrt, again

Mark Dickinson added the comment: Some comments, now that I've had a chance to look properly at the suggestion. For reference, here's the "near square root" function that forms the basis of Python's isqrt algorithm. For clarity, I've written it recursively, but it's

[issue43053] Speed up math.isqrt, again

Mark Dickinson added the comment: > As it currently stands, `a - (a*a > n)` is computed both in `isqrt` and > `isqrt_2`. So I was thinking that maybe the former might be dropped. Ah, sorry; I misunderstood. Yes, I think so. I'll respond more fully later. (Sorry - real lif

[issue43053] Speed up math.isqrt, again

Mark Dickinson added the comment: > the only thing I'm not sure about is whether the final correction in the > original `isqrt` is needed Well, *some* part of the algorithm has to make use of the low-order bits of n. Otherwise we won't be able to distinguish n = 4a**2 + 4a + 1 (whose

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: @Eric: Are you okay with closing this issue, or do you think we should leave it open as a reminder to write that PEP? -- ___ Python tracker <https://bugs.python.org/issue43

[issue43053] Speed up math.isqrt, again

Mark Dickinson added the comment: Thanks; I'll take a look at this at the weekend. Do you have a sketch of a proof of correctness available? -- assignee: -> mark.dickinson ___ Python tracker <https://bugs.python.org/issu

[issue43040] random.py randrange() is very slow if the range is a power of 2.

Mark Dickinson added the comment: @Donovan: Please get Raymond Hettinger's sign-off before merging anything. In #37000, the decision not to change things wasn't because we missed a fix, but rather because it was decided that it was better to leave things as they were. I don't think

[issue43040] random.py randrange() is very slow if the range is a power of 2.

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

[issue43032] Size of pie chart in matplotlib (frame affects it)

Mark Dickinson added the comment: Wrong tracker, I'm afraid. This tracker is for the Python core language. Try https://github.com/matplotlib/matplotlib/issues -- nosy: +mark.dickinson resolution: -> third party stage: -> resolved status: open -&g

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: [Serhiy] > Just making the parser [...] recognizing "i" as well as "j" as complex number > suffix. Okay, thanks. I doubt that that will be enough to silence the repeated requests: people are still going to complain that the valu

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: Serhiy: what *specific* proposal were you considering? If your proposal includes changing the complex str/repr to use "i" instead of "j", how do you propose to address the backwards c

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: > cmath.nanj That should be cmath.nani, of course. Sorry. -- ___ Python tracker <https://bugs.python.org/issue43025> ___ _

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: See also #10562. Conceivably, we could add support for `i` on parsing (along with adding `cmath.infi` and `cmath.nanj`). We can probably also find a way to extend the format specification to allow use of `i` in place of `j` on output. The harder problem

[issue43002] Exception chaining accepts exception classes

Change by Mark Dickinson : -- pull_requests: +23124 pull_request: https://github.com/python/cpython/pull/24303 ___ Python tracker <https://bugs.python.org/issue43

[issue43002] Exception chaining accepts exception classes

Mark Dickinson added the comment: Ram: I think you're conflating two separate things, here: (1) The ability to use an exception *class* instead of an exception *instance* in the "from" clause - that is, the ability to do "raise ValueError from TypeError" in place of &q

[issue42911] Addition chains for pow saves 5-20% time for pow(int, int)

Mark Dickinson added the comment: Thank you for the proposal and PR! There are some tradeoffs to be considered here, between simplicity and performance; it's not always trivial to find the sweet spot. Python's int implementation mostly favours the simplicity end of the spectrum. It's also

[issue42936] Decimal module performs wrong floor division with negative numbers

Mark Dickinson added the comment: Thanks for the report. I'm going to close here, since this isn't a bug. If you want to advocate for a behaviour change, by all means go ahead, but be aware that it would likely be a hard sell. The main challenge would be finding a way to change

[issue42936] Decimal module performs wrong floor division with negative numbers

Mark Dickinson added the comment: The behaviour is deliberate, if unfortunate: it's covered in the documentation here: https://docs.python.org/3/library/decimal.html#decimal-objects - see the paragraph starting > There are some small differences between arithmetic on Decimal obje

[issue42879] SystemError from class 'int'

Mark Dickinson added the comment: Downstream issue is here: https://github.com/pygame/pygame/issues/2442 I'll close this here, since that report indicates a bug in Pygame. -- resolution: -> third party stage: -> resolved status: open -&g

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

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

[issue42886] math.log and math.log10 domain error on very large Fractions

Mark Dickinson added the comment: @Camion: Can you say more about your use-case? One thing that's on my would-be-nice-to-do-one-day list is 'e', 'f' and 'g'-style decimal formatting for Fraction objects. Without that, it's often hard to get a quick sense of the magnitude of a Fraction

[issue42879] SystemError from class 'int'

Mark Dickinson added the comment: This is more likely to be a bug in Pygame than in Python itself. What's likely happening here is that some part of the Pygame machinery is setting an exception state but then returning a value as normal. (Generally, if some function in a C extension sets

[issue42873] Exponential time and space requirements for compilation of nested try/finally blocks

Mark Dickinson added the comment: > I don't see what the problem is here. People just don't write code like that. Yes, agreed; as I said in the original post, I'm not expecting any action, but the effect did seem interesting enough to be worth noting in an issue (if only so that it

[issue42873] Exponential time and space requirements for compilation of nested try/finally blocks

Mark Dickinson added the comment: > And there may be more than one return/break/continue statement in the try > block. It increases the base of the degree. Ah, interesting. My understanding was that that can't happen, but I'll double check. In the control flow, all 'return' stat

[issue42873] Exponential time and space requirements for compilation of nested try/finally blocks

Mark Dickinson added the comment: For extra fun, you can add `break` and `continue` paths into the mix to get a 5-fold instead of 3-fold code size increase per level of nesting. It's still contrived code, though. Example where do_cleanup() ends up with 5**4 = 625 paths: def f

[issue42873] Exponential time and space requirements for compilation of nested try/finally blocks

New submission from Mark Dickinson : tl;dr - contrived (but relatively short) code involving nested try/finally blocks can produce disproportionately large bytecode. I'm not expecting or suggesting any action here, but the situation seemed at least worth noting. Feel free to close this issue

[issue42454] Move slice creation to the compiler for constants

Mark Dickinson added the comment: @Batuhan Taskaya: would it be worth starting a discussion on either python-ideas or python-dev? (Or on discuss.python.org.) My concern is that we're discussing a core language change. It's not a major change, but it's not an insignificant one either

[issue42792] [MacOS] Can't open file in a separate (threading.Thread) thread

Mark Dickinson added the comment: Your test file has the line: f = open("lol.txt", "r", "utf-8") But the third positional argument to the 'open' built-in function is "buffering", which expects an integer. Pass the "utf-8" argument by nam

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

Mark Dickinson added the comment: > RFC 8259 (current RFC for JSON): https://tools.ietf.org/html/rfc7159 Argh; copy-and-paste fail. That link should have been https://tools.ietf.org/html/rfc8259, of course. -- ___ Python tracker <

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

Mark Dickinson added the comment: For the record, some helpful resources: ECMA-404 (the ECMA standardization of JSON): http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf RFC 8259 (current RFC for JSON): https://tools.ietf.org/html/rfc7159. (I mistakenly referred

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

Mark Dickinson added the comment: @Luca: you might want to open a new feature request issue; it's not clear to me what exact behaviour change you're proposing for Python. What was rejected in this issue was the proposal to *automatically* convert NaNs and infinities to nulls by default

[issue42665] Should PyLong_AsLongAndOverflow raise exception on overflow?

Mark Dickinson added the comment: @ganesh3597. PyLong_AsLongAndOverflow is behaving as intended, and changes to the behaviour would break existing code. If you think there's a case for changing the behaviour, you'd need to provide your rationale for the change, details of what you propose

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

Mark Dickinson added the comment: > Should this issue be closed, or are you thinking of more changes? I've made one more round of changes in GH-23575. Once that's gone in, I think we can close this issue. I don't think we're ever going to be able to make this table perfectly accur

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

Change by Mark Dickinson : -- pull_requests: +22455 pull_request: https://github.com/python/cpython/pull/23575 ___ Python tracker <https://bugs.python.org/issue39

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

Mark Dickinson added the comment: The 'default precision' issue is addressed; the issues that Michael reported about the `None` presentation type are still valid, I think. -- ___ Python tracker <https://bugs.python.org/issue39

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

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

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

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

[issue42496] Don't change indentation of RST markup

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

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

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

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

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

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

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

[issue42454] Move slice creation to the compiler for constants

Mark Dickinson added the comment: > At least for optimization, IMHO it worth taking the shot. For me, this feels a bit backwards: IMO you should decide what behaviour you want first, implement the desired behaviour, and then optimize (if possible) while keeping that same desired behavi

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

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

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

Mark Dickinson added the comment: There's also #39096. -- ___ Python tracker <https://bugs.python.org/issue42429> ___ ___ Python-bugs-list mailing list Unsub

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

Mark Dickinson added the comment: Some references after a bit of tracker digging: - #7098 is the original issue where the behaviour was considered. - #23460 is related, and _did_ result in a documentation change, but that documentation change didn't say anything about preserving trailing

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

Mark Dickinson added the comment: Hmm. I'm not sure that it ever got documented properly. There may still be an open documentation issue somewhere. There's not really much wiggle-room for changing the implementation: the behaviour of the "g" formatting for Decimal objects is

[issue42428] Inconsistent squaring behavior

Mark Dickinson added the comment: -3 ** 2 is parsed by Python as -(3 **2), not as (-3) ** 2. -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue42

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

Mark Dickinson added the comment: @Arjan Staring: could you point to which part of the JSON specification you're looking at? At https://tools.ietf.org/html/rfc7159, the only reference to NaNs that I see is: > Numeric values that cannot be represented in the grammar be

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

Mark Dickinson added the comment: [Victor] > How can we fix the buildbot? Add #ifdef in mathmodule.c to implement the > special cases, but only on AIX? Skip the test? I'm not super-keen on using #ifdefs to implement the special-case handling _just_ for AIX: that opens th

[issue42334] Subclassing int and complex with keyword arguments weird

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

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

Mark Dickinson added the comment: > My worry is that I'm getting emails about AIX buildbot failures. That sounds more like a process problem than a CPython codebase one. The ideal would be that the machinery sending those notifications can be configured to ignore known failures w

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

Mark Dickinson added the comment: Is there any reasonable channel for reporting the issue upstream? -- ___ Python tracker <https://bugs.python.org/issue42

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

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

[issue20543] ** operator does not overflow to inf

Mark Dickinson added the comment: Thanks, @iritkatriel. Sounds good to me. -- stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/i

[issue42210] float.hex discards sign from -nan

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

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

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

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

Mark Dickinson added the comment: [Guido] > Possibly at some point in the future we can switch to using typing.Protocol > [...] Yes, I think there's an interesting wider problem here, that typing.Protocol might be the answer to. For numbers and collections.abc in the std. lib., I'm

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

Mark Dickinson added the comment: Ok, so we need to either (a) revert PR 6121 and then re-do the changes, without the changes to numbers.py, or (b) make a second PR to undo the numbers.py changes. I think there's (calendar) time available for option (b), but I'm not going to have bandwidth

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

Mark Dickinson added the comment: > When a concrete class registers with an ABC, it is making a promise that it > implements everything in the ABC. Ah, interesting. I would have assumed that it's only making a promise that it registers all the methods and properties marked *ab

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

Mark Dickinson added the comment: > That still amounts to making it a requirement for all numeric classes How so? I don't follow the reasoning here. -- ___ Python tracker <https://bugs.python.org/issu

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

Mark Dickinson added the comment: I interpreted "in the numeric tower" as meaning declared as an abstract method that all those registering with the class would have to implement. As you point out in msg350173, that would be problematic - adding new methods to published interfaces

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

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

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

Mark Dickinson added the comment: > Do we need another fast-path in long_div(a, b) when b == _PyLong_One? Just > return a in this case. I'd much prefer not. Every extra fast path check costs time for the general case, and there's no strong reason to expect people to be dividing

[issue41823] Add more fields to sys.float_info

Mark Dickinson added the comment: Double rounding is a property of how operations on floats are carried out, rather than being a property of the float format itself; I'm not sure that it belongs in float_info. It's also potentially ill-defined. Right now, as far as I *know*, it seems

[issue39385] Add an assertNoLogs context manager to unittest TestCase

Change by Mark Dickinson : -- nosy: +mark.dickinson nosy_count: 8.0 -> 9.0 pull_requests: +21362 pull_request: https://github.com/python/cpython/pull/22317 ___ Python tracker <https://bugs.python.org/issu

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

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

[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 : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41487> ___ ___

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