[issue45332] Decimal test and benchmark are broken

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

[issue36841] Supporting customization of float encoding in JSON

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

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

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

[issue44019] operator.call/operator.__call__

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

[issue44019] operator.call/operator.__call__

Mark Dickinson added the comment: Thanks for the contribution! -- stage: patch review -> resolved status: open -> closed type: -> enhancement ___ Python tracker <https://bugs.python.or

[issue44019] operator.call/operator.__call__

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

[issue45218] cmath.log has an invalid signature

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 binar

[issue45218] cmath.log has an invalid signature

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

[issue45218] cmath.log has an invalid signature

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

[issue45218] cmath.log has an invalid signature

Change by Mark Dickinson : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue45218> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue45218] cmath.log has an invalid signature

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", "credi

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

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

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

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

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

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

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

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/8ca6b61e3fd7f1e2876126cee82da8

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

Mark Dickinson added the comment: All done, I think. Closing. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue14613] time.time can return NaN

Mark Dickinson added the comment: > I propose we close it [...] Seconded! -- stage: test needed -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.or

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

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 erro

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

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 stand

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

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

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

Change by Mark Dickinson : -- pull_requests: +26360 pull_request: https://github.com/python/cpython/pull/27902 ___ Python tracker <https://bugs.python.org/issue24

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

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 b

[issue44019] operator.call/operator.__call__

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

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

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

[issue44977] Deprecate delegation of int to __trunc__?

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

[issue44977] Deprecate delegation of int to __trunc__?

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

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

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

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

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

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

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

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

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

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

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 <ht

[issue44978] Argument Clinic should not exclude __complex__ methods

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

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

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

[issue44978] Argument Clinic should not exclude __complex__ methods

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

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

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 giv

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

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__

[issue44978] Argument Clinic should not exclude __complex__ methods

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

[issue44978] Argument Clinic should not exclude __complex__ methods

New submission from Mark Dickinson : The argument clinic currently refuses to handle a __complex__ method. However, unlike __int__ and __float__, __complex__ should require no special handling by the argument clinic, since there's no dedicated slot for the __complex__ method. PR arriving

[issue44977] Deprecate delegation of int to __trunc__?

Mark Dickinson added the comment: > This decouples int from __trunc__ and leaves __trunc__ as simply the support > for the math.trunc function. Argh; copy and paste fail - I left out the crucial line. I propose deprecating the delegation of int to __trunc__: calls to int(a) where

[issue44977] Deprecate delegation of int to __trunc__?

New submission from Mark Dickinson : The int constructor, when applied to a general Python object `obj`, first looks for an __int__ method, then for an __index__ method, and then finally for a __trunc__ method. The delegation to __trunc__ used to be useful: it meant that users could write

[issue44547] fraction.Fraction does not implement __int__.

Mark Dickinson added the comment: I think there's no reason not to keep __trunc__ and math.trunc - they're natural counterparts to floor and ceil, and there's probably at least some code out there already using math.trunc. It's the involvement of __trunc__ in the int() builtin that I'd

[issue44970] Re-examine complex pow special case handling

Mark Dickinson added the comment: Aargh. Brain fail. There *is* no `cmath.pow`, of course; this issue applies only to `**` and the built-in `pow`. -- ___ Python tracker <https://bugs.python.org/issue44

[issue44970] Re-examine complex pow special case handling

Mark Dickinson added the comment: Here's just one example that doesn't make a whole lot of sense: in this case, z ** 1 should be returning z. >>> z = complex(3, float("inf")) >>> z ** 1 Traceback (most recent call last): File "", line 1, in

[issue44970] Re-examine complex pow special case handling

New submission from Mark Dickinson : Complex power, both via `**` and the built-in `pow`, and via `cmath.pow`, is currently a bit of a mess when it comes to special-case handling - particularly handling of signed zeros, infinities, NaNs, and overflow. At some point it would be nice

[issue30999] statistics module: add a general selection function

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

[issue44954] Bug in float.fromhex

Mark Dickinson added the comment: All fixed! Closing. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior ___ Python tracker <https://bugs.python

[issue44954] Bug in float.fromhex

Mark Dickinson added the comment: Fixed in the main branch and in 3.9; 3.10 is very close to release, so the backport PR for 3.10 may have to wait for 3.10.1 (which wouldn't really be a problem, given that this bug has apparently lain unnoticed since Python 2.7). That's Pablo's call

[issue44954] Bug in float.fromhex

Mark Dickinson added the comment: New changeset 7ef0673de48958bc3a75af5f152564bd2dffa8dd by Miss Islington (bot) in branch '3.9': bpo-44954: Fix wrong result in float.fromhex corner case (GH-27834) (GH-27855) https://github.com/python/cpython/commit/7ef0673de48958bc3a75af5f152564bd2dffa8dd

[issue44954] Bug in float.fromhex

Mark Dickinson added the comment: New changeset 60b93d9e4922eeae25052bc15909d1f4152babde by Mark Dickinson in branch 'main': bpo-44954: Fix wrong result in float.fromhex corner case (GH-27834) https://github.com/python/cpython/commit/60b93d9e4922eeae25052bc15909d1f4152babde

[issue44960] Add regression test for geometric test

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

[issue27353] Add nroot function to math

Mark Dickinson added the comment: [Irit] > Is this still needed? It's not needed for geometric_mean. It's still a reasonable feature request, but it would be non-trivial effort to put a good quality implementation together - C doesn't have this function, so we can't simply wrap it like

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

Change by Mark Dickinson : -- assignee: docs@python -> mark.dickinson ___ Python tracker <https://bugs.python.org/issue44344> ___ ___ Python-bugs-list mai

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

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

[issue16801] Preserve original representation for integers / floats in docstrings

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

[issue44728] Testsuite fails on x86_64

Mark Dickinson added the comment: One more thought on the libm issues - from the logs, it looks as though the libm implementation is coming from a fairly recent version of glibc (glibc 2.33, which was released in February 2021). There were updates to the 'exp' implementation in glibc

[issue28327] statistics.geometric_mean gives incorrect results for mixed int/float inputs

Mark Dickinson added the comment: > Is this issue about a previous version? Yep. Sorry for failing to close this earlier. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker <https://

[issue28111] geometric_mean can raise OverflowError for large input length

Mark Dickinson added the comment: Thanks, @Irit. Yes, this is about a different version of geometric_mean that didn't end up making it into any release. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Pytho

[issue44547] fraction.Fraction does not implement __int__.

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

[issue44625] Python C API version of `fractions` module

Mark Dickinson added the comment: Closing here. I think we'd need a PEP and a wider discussion to take this forward. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

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

[issue44728] Testsuite fails on x86_64

Mark Dickinson added the comment: Here's the test_posix failure, extracted from the attachment: == ERROR: test_sched_rr_get_interval (test.test_posix.PosixTester

[issue44728] Testsuite fails on x86_64

Mark Dickinson added the comment: Update: test_turtle is fixed (44734); I think test_math and test_cmath should be resolved as either "third party" or "wont fix", since the issue is almost certainly the platform libm. That leaves test_posix, which we should probabl

[issue21111] Add a new PyLong_AsUnsignedLongAndOverflow function

Mark Dickinson added the comment: Let's close this one. The patch is stale, and I think we should be somewhat cautious about expanding the C-API without clear use-cases - I don't think it's worth adding the new function just for symmetry / consistency. I'm happy to re-open if those use

[issue44954] Bug in float.fromhex

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

[issue44954] Bug in float.fromhex

Mark Dickinson added the comment: The bug is in this line: https://github.com/python/cpython/blob/3db42fc5aca320b0cac1895bc3cb731235ede794/Objects/floatobject.c#L1467 which reads: (half_eps == 8 && (HEX_DIGIT(key_digit+1) & 1) != 0)) In the buggy case,

[issue44954] Bug in float.fromhex

Mark Dickinson added the comment: Thanks for the report! I can reproduce the issue, and agree with your analysis. -- assignee: -> mark.dickinson nosy: +mark.dickinson versions: +Python 3.10, Python 3.11 ___ Python tracker <https://bugs.pyth

[issue44946] Integer operations are inefficient for "medium" integers.

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

[issue44946] Integer operations are inefficient for "medium" integers.

Mark Dickinson added the comment: See also #21955, #10044, and https://github.com/python/cpython/blob/3240bc62f4e0afa09964f3afc845697f0a0806b9/Python/ceval.c#L1986-L1991 -- ___ Python tracker <https://bugs.python.org/issue44

[issue44946] Integer operations are inefficient for "medium" integers.

Mark Dickinson added the comment: We already special-case medium integers in the Objects/longobject.c code, in various places. For example for addition, here: https://github.com/python/cpython/blob/3240bc62f4e0afa09964f3afc845697f0a0806b9/Objects/longobject.c#L3070-L3072 Are you proposing

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: Re-closing; we should be good now. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: New changeset beb3a835dae3cd940b93e7caa32450890c4cd539 by Miss Islington (bot) in branch '3.9': bpo-44698: Restore complex pow behaviour for small integral exponents (GH-27772) (GH-27797) https://github.com/python/cpython/commit

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: New changeset 3f81e9628f6f104c103d0e38adb84c51e5261626 by Miss Islington (bot) in branch '3.10': bpo-44698: Restore complex pow behaviour for small integral exponents (GH-27772) (GH-27796) https://github.com/python/cpython/commit

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: New changeset 4b9a2dcf19e5d13c3bc2afea2de1f65cd994c699 by Mark Dickinson in branch 'main': bpo-44698: Restore complex pow behaviour for small integral exponents (GH-27772) https://github.com/python/cpython/commit/4b9a2dcf19e5d13c3bc2afea2de1f65cd994c699

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: Thanks, Pablo! > could you add me as a reviewer for the backport Will do! I'll waiting on review for the PR against the main branch, but hope to get the backport PR up by this coming weekend at the lat

[issue16580] [doc] Add examples to int.to_bytes and int.from_bytes

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

[issue16580] [doc] Add examples to int.to_bytes and int.from_bytes

Mark Dickinson added the comment: Merged. Thank you for the contribution! -- ___ Python tracker <https://bugs.python.org/issue16580> ___ ___ Python-bugs-list m

[issue16580] [doc] Add examples to int.to_bytes and int.from_bytes

Mark Dickinson added the comment: New changeset ad0a8a9c629a7a0fa306fbdf019be63c701a8028 by Gautam Chaudhuri in branch 'main': bpo-16580: [doc] Add examples to int.to_bytes and int.from_bytes (GH-27760) https://github.com/python/cpython/commit/ad0a8a9c629a7a0fa306fbdf019be63c701a8028

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: @Pablo: I'm adding you to the nosy list to get your opinion on whether (the backport of) GH-27772 can go into 3.10.0.rc2. Summary: GH-27278 (which I reviewed and approved) and its backports fixed some undefined behaviour in complex exponentiation, but also

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

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

[issue16580] [doc] Add examples to int.to_bytes and int.from_bytes

Mark Dickinson added the comment: @Gautam > I think it's out of scope for this issue. Agreed. It was just a note in passing. I don't think it's worth opening a new issue, though, unless this is genuinely causing problems for someone. Just let it

[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section

Mark Dickinson added the comment: > do you feel like that new article is a good drop-in replacement for the old > one? No really, no. :-( I also now see that the new article has a (broken) link to the old article, which makes me think that maybe the removal of the old a

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: > brave or foolhardy enough to try to figure out what all of the special case > results *should* be for complex pow Addendum: even the C standards give up at this point. For everything else the special cases are spelled out in detail, but for cpow, f

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by Mark Dickinson : -- assignee: twouters -> mark.dickinson status: closed -> open ___ Python tracker <https://bugs.python.org/issue44698> ___ ___

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: > a double-check that the behaviour change is desirable I'm not sure I'm brave or foolhardy enough to try to figure out what all of the special case results *should* be for complex pow. The special cases seem reasonably clear cut for everything e

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: Thanks, @seberg. I'll take a look and see if we can restore the old behaviour, at least for Python 3.9 and 3.10. I'm not convinced that the new behaviour is objectively wrong, but I agree that the *change* in behaviour is problematic. I do find it a little

[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section

Mark Dickinson added the comment: A bit more Googling found this: https://support.mozilla.org/en-US/kb/contributors-guide-writing-good-bug -- ___ Python tracker <https://bugs.python.org/issue44

[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section

New submission from Mark Dickinson : The "Bug Report Writing Guidelines" link in the "Dealing with Bugs" doc section (https://docs.python.org/3/bugs.html) looks broken. The linked URL is https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines, but t

[issue44820] subprocess hungs when processing value from mariadb

Mark Dickinson added the comment: Hi @jb. This tracker is for reporting bugs in the core Python language. While it's possible that what you're experiencing is due to a bug in core Python, on the information given it's likely that the problem is either in your own code, or in whatever

[issue44814] python 3.9.6 installation installs 0 modules

Mark Dickinson added the comment: Setting as pending. It looks as though this report represents a misunderstanding of how Python works rather than a bug in Python. -- nosy: +mark.dickinson resolution: -> not a bug status: open -> p

[issue43596] change assertRaises message when wrong exception is raised

Mark Dickinson added the comment: I think I understand where the request comes from: in the case where you've changed the exception type that an API is expected to raise, and you've either updated the test to check for the new exception type and missed an update in the business logic

[issue44734] turtle: tests for Vec2D.__abs__ are too strict

Change by Mark Dickinson : -- keywords: +easy ___ Python tracker <https://bugs.python.org/issue44734> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44728] Testsuite fails on x86_64

Mark Dickinson added the comment: Looks like the turtle code was changed to use `math.hypot` instead of `** 0.5` in issue #41528. That will likely also fix the test failure, but I've opened #44734 to fix the unnecessarily strict test

[issue44734] turtle: tests for Vec2D.__abs__ are too strict

Change by Mark Dickinson : -- type: -> behavior versions: +Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44734> ___ _

[issue44734] turtle: tests for Vec2D.__abs__ are too strict

New submission from Mark Dickinson : >From the tests for Vec2D.__abs__ in the turtle module we have: def test_distance(self): vec = Vec2D(6, 8) expected = 10 self.assertEqual(abs(vec), expected) vec = Vec2D(0, 0) expected

[issue44728] Testsuite fails on x86_64

Mark Dickinson added the comment: The test_posix failure appears to be unrelated; I'll let others look into that one. The test_turtle failure looks again like a libm issue, perhaps combined with an overeager test: we're expecting a `** 0.5` operation (which translates to a libm pow call

[issue44728] Testsuite fails on x86_64

Mark Dickinson added the comment: Extract from the log - from the configure output: > checking for expm1... yes and from the test output > expm10118: expm1(27.0): expected 532048240600.79865, got 532048240600.7976 > (error = 0.00104 (17 ulps); permitted error = 0 or 5 ulps) &g

[issue44651] An unclear definition in Doc/glossary.rst

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

[issue44651] An unclear definition in Doc/glossary.rst

Mark Dickinson added the comment: New changeset c05a790693b3b00ac7cb5b96ad416ca9d8ecb14a by Steven Hsu in branch 'main': bpo-44651: delete entry of "coercion" in Doc/glossary.rst (GH-27226) https://github.com/python/cpython/commit/c05a790693b3b00ac7cb5b96ad416c

[issue44651] An unclear definition in Doc/glossary.rst

Mark Dickinson added the comment: My one worry with removing the entry is that documentation of other projects may be referring to it via intersphinx. If we think this is likely to be a real problem, we could leave a stub entry, but I think it's okay to go ahead and delete

[issue44651] An unclear definition in Doc/glossary.rst

Mark Dickinson added the comment: Searching further, none of the uses of "coerce" or "coercion" in the docs seem to be a good match for the definition in this glossary entry. For example, from ipaddress.rst: > By default, attempting to create a network object with ho

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