[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

[issue42560] Improve Tkinter Documentation

Change by Mark Roseman : -- pull_requests: +26306 pull_request: https://github.com/python/cpython/pull/27842 ___ Python tracker <https://bugs.python.org/issue42

[issue42560] Improve Tkinter Documentation

Change by Mark Roseman : -- pull_requests: +26304 pull_request: https://github.com/python/cpython/pull/27840 ___ Python tracker <https://bugs.python.org/issue42

[issue42560] Improve Tkinter Documentation

Change by Mark Roseman : -- pull_requests: +26303 pull_request: https://github.com/python/cpython/pull/27839 ___ Python tracker <https://bugs.python.org/issue42

[issue42560] Improve Tkinter Documentation

Change by Mark Roseman : -- pull_requests: +26302 pull_request: https://github.com/python/cpython/pull/27838 ___ Python tracker <https://bugs.python.org/issue42

[issue42560] Improve Tkinter Documentation

Change by Mark Roseman : -- pull_requests: +26300 pull_request: https://github.com/python/cpython/pull/27836 ___ Python tracker <https://bugs.python.org/issue42

[issue42560] Improve Tkinter Documentation

Change by Mark Roseman : -- pull_requests: +26299 pull_request: https://github.com/python/cpython/pull/27835 ___ Python tracker <https://bugs.python.org/issue42

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

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

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

[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

[issue44850] Could operator.methodcaller be optimized using LOAD_METHOD?

Mark Shannon added the comment: If the problem is that methodcaller is not faster than a lambda, then why not use a lambda? Lambdas are just Python functions and calling them will get faster. We aren't going to spend time optimizing calls to methodcaller, so you might as well use a lambda

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

Mark Shannon added the comment: Just changes to longobject.c. There are still various minor inefficiencies in testing to see whether an int is a medium value, and then throwing away size information before creating result objects. I'm not expecting this to make much difference, but every

[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

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

New submission from Mark Shannon : "Medium" integers are those with a single internal digit or zero. Medium integers are integers in the range -2**30 to +2**30 on 64 bit machines. "Small" integers, -5 to 256 are cached, but are represented as medium integers in

[issue44945] Specialize BINARY_ADD using PEP 659 machinery.

New submission from Mark Shannon : Specializing BINARY_ADD is worthwhile for two reasons: Specializing for ints, floats and strings may give us some small speedup. It removes the complex checks for the special case of extending a string, `s = s + ...` from the normal instruction

[issue44878] Clumsy dispatching on interpreter entry.

Mark Shannon added the comment: I'm somewhat surprised by that. After all, the only change in control flow was the change from a break to a goto in exception handling. I would have expected PR27726 to have made much more difference. There are a few possibilities, including: 1. It's just

[issue44895] refleak test failure in test_exceptions

Mark Shannon added the comment: refleak.py seems to run forever for me. Got bored after 6000 iterations. Which O/S and configure options are needed for refleak.py to fail? -- ___ Python tracker <https://bugs.python.org/issue44

[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

[issue42560] Improve Tkinter Documentation

Mark Roseman added the comment: Łukasz, I've got a bunch of individual branches for each of those sections. What I posted the link to was a merge of all of them just for overview purposes, but the PR's will be created from the individual branches. I can start creating those now or wait a bit

[issue44889] Specialize LOAD_METHOD with PEP 659 adaptive interpreter

Mark Shannon added the comment: New changeset 96346cb6d0593ef9ec122614347ccb053cd63433 by Ken Jin in branch 'main': bpo-44889: Specialize LOAD_METHOD with PEP 659 adaptive interpreter (GH-27722) https://github.com/python/cpython/commit/96346cb6d0593ef9ec122614347ccb053cd63433

[issue42560] Improve Tkinter Documentation

Mark Roseman added the comment: I would most definitely echo the concern about the massive size of such a project as well as future maintainability. I don't know anyone who would be able to do such a thing on a volunteer basis, and I think it would be highly unlikely that anyone would step

[issue44914] tp_version_tag is not unique when test runs with -R :

Mark Shannon added the comment: New changeset d84d2c4985457733602d46dc4ee77290da4e9539 by Ken Jin in branch 'main': bpo-44914: Add tests for some invariants of tp_version_tag (GH-27774) https://github.com/python/cpython/commit/d84d2c4985457733602d46dc4ee77290da4e9539

[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

[issue44900] Implement superinstructions

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

[issue44900] Implement superinstructions

Mark Shannon added the comment: New changeset 4f51fa9e2d3ea9316e674fb9a9f3e3112e83661c by Mark Shannon in branch 'main': bpo-44900: Add five superinstructions. (GH-27741) https://github.com/python/cpython/commit/4f51fa9e2d3ea9316e674fb9a9f3e3112e83661c

[issue44914] tp_version_tag is not unique when test runs with -R :

Mark Shannon added the comment: New changeset 1a511dc92dd10ee8fc2e5da9f52f795924bdc89a by Mark Shannon in branch 'main': bpo-44914: Maintain invariants of type version tags. (GH-27773) https://github.com/python/cpython/commit/1a511dc92dd10ee8fc2e5da9f52f795924bdc89a

[issue44240] Incorrect behavior of LOAD_ATTR due to overflow in tp_version

Change by Mark Shannon : -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> tp_version_tag is not unique when test runs with -R : ___ Python tracker <https://bugs.python

[issue42560] Improve Tkinter Documentation

Mark Roseman added the comment: Here's a very rough work-in-progress snapshot: https://github.com/roseman/cpython/blob/tkinter-docs-snapshot-20210815/Doc/library/tkinter.rst This includes: 1. Changes I'd mentioned to the intro, external resources, modules, architecture 2. Rewrite

[issue44914] tp_version_tag is not unique when test runs with -R :

Mark Shannon added the comment: PyType_ClearCache() is documented as: Clear the internal lookup cache. Return the current version tag. Modifying it to do what it is documented to do fixes this bug :) -- ___ Python tracker <ht

[issue44914] tp_version_tag is not unique when test runs with -R :

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

[issue44914] tp_version_tag is not unique when test runs with -R :

Mark Shannon added the comment: Thanks for putting in the effort to find this. I think the first step to fixing this is to formalize the semantics of `tp_version_tag`. Initially it was designed just for the method cache, but we have started using it as a unique identifier for the state

[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

[issue44918] Unhandled Exception (Not Implemented) in HTMLParser().feed

New submission from Mark Deen : The hexadecimal sequence '3c215b02634717' when passed as an argument to HTMLParser()'s feed function results in the exception noted below. The code example below illustrates this exception. from html.parser import HTMLParser parser = HTMLParser() parser.feed

[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

[issue44917] interpreter hangs on recursion in both body and handler of a try block

Mark Shannon added the comment: A recursion limit of 30 is effectively infinite. With a debug build of 3.11, the time to execute grows very fast indeed, probably super-exponentially. mark@nero:~/repos/cpython$ time ./python ~/test/test.py 15 real0m1.107s user0m1.099s sys

[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

[issue44917] interpreter hangs on recursion in both body and handler of a try block

Mark Shannon added the comment: This looks like a duplicate of https://bugs.python.org/issue42951 -- nosy: +Mark.Shannon ___ Python tracker <https://bugs.python.org/issue44

[issue40116] Regression in memory use of shared key dictionaries for "compact dicts"

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

[issue44772] Regression in memory use of instances due to dictionary ordering

Mark Shannon added the comment: Duplicate of https://bugs.python.org/issue40116 -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41703] Most bytecode changes are absent from Python 3.9 What's new

Change by Mark Shannon : -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42837] Symbol table incorrectly identifies code as a generator, when 'yield' occurs in an annotation

Mark Shannon added the comment: I guess this will be resolved when the great PEP 563/649 debate is concluded. No need for another issue. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracke

[issue40222] "Zero cost" exception handling

Mark Shannon added the comment: I'd like to close this, as the exception handling is all done and working correctly. Is there a separate issue for how we are handling CodeType()? -- ___ Python tracker <https://bugs.python.org/issue40

[issue44450] Generator expressions trace differently on Windows than on Mac

Mark Shannon added the comment: Ned, is this still an issue with the release candidate of 3.10? -- ___ Python tracker <https://bugs.python.org/issue44

[issue44297] Frame with -1 line number

Mark Shannon added the comment: I believe this to be fixed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42560] Improve Tkinter Documentation

Change by Mark Roseman : -- nosy: +lukasz.langa, terry.reedy ___ Python tracker <https://bugs.python.org/issue42560> ___ ___ Python-bugs-list mailing list Unsub

[issue42560] Improve Tkinter Documentation

Mark Roseman added the comment: Here are my broad suggestions for improvement (each of these would turn into a separate PR). Thoughts for/against each? 1. 'See also' section: use this to guide people to what they need. update to point out challenge of finding material given age etc

[issue44900] Implement superinstructions

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

[issue44900] Implement superinstructions

New submission from Mark Shannon : PEP 659 quickening provides a mechanism for replacing instructions. We should exploit this to implement superinstructions when quickening. See https://github.com/faster-cpython/ideas/issues/16 -- messages: 399444 nosy: Mark.Shannon priority: normal

[issue44890] Enable specialization stats collection when in Py_DEBUG

Mark Shannon added the comment: New changeset 8ac0886091c27bf4b6bb0a9b571e174b554d31a4 by Irit Katriel in branch 'main': bpo-44890: collect specialization stats if Py_DEBUG (GH-27731) https://github.com/python/cpython/commit/8ac0886091c27bf4b6bb0a9b571e174b554d31a4 -- nosy

[issue44878] Clumsy dispatching on interpreter entry.

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

[issue44878] Clumsy dispatching on interpreter entry.

Mark Shannon added the comment: New changeset a530a9538f3f444bebd2d2b71fe5f2e747e76d73 by Mark Shannon in branch 'main': bpo-44878: Remove loop from interpreter. All dispatching is done by gotos. (GH-27727) https://github.com/python/cpython/commit/a530a9538f3f444bebd2d2b71fe5f2e747e76d73

[issue42560] Improve Tkinter Documentation

Mark Roseman added the comment: I was having a peek at the main tkinter doc page again and would like to take a broader crack at it. I think most of what is there now (life preserver/reference) needs to be substantially reworked or trimmed. I think exhaustive description of all methods etc

[issue44878] Clumsy dispatching on interpreter entry.

Change by Mark Shannon : -- pull_requests: +26208 pull_request: https://github.com/python/cpython/pull/27727 ___ Python tracker <https://bugs.python.org/issue44

[issue44878] Clumsy dispatching on interpreter entry.

Mark Shannon added the comment: New changeset f66d00fdd7e9a333accc6bf0e37173051aaa55d0 by Mark Shannon in branch 'main': bpo-44878: Remove the switch from the main interpreter loop when using computed gotos. (GH-27726) https://github.com/python/cpython/commit

[issue44878] Clumsy dispatching on interpreter entry.

Change by Mark Shannon : -- pull_requests: +26206 pull_request: https://github.com/python/cpython/pull/27726 ___ Python tracker <https://bugs.python.org/issue44

[issue44878] Clumsy dispatching on interpreter entry.

Mark Shannon added the comment: New changeset 3f3d5dcac336463bd0eed64ba0bd7666ff2da1e1 by Mark Shannon in branch 'main': bpo-44878: _PyEval_EvalFrameDefault readability improvements (GH-27725) https://github.com/python/cpython/commit/3f3d5dcac336463bd0eed64ba0bd7666ff2da1e1

[issue44878] Clumsy dispatching on interpreter entry.

Change by Mark Shannon : -- pull_requests: +26205 pull_request: https://github.com/python/cpython/pull/27725 ___ Python tracker <https://bugs.python.org/issue44

[issue33479] Document tkinter and threads

Change by Mark Roseman : -- pull_requests: +26200 pull_request: https://github.com/python/cpython/pull/27717 ___ Python tracker <https://bugs.python.org/issue33

[issue44878] Clumsy dispatching on interpreter entry.

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

[issue44878] Clumsy dispatching on interpreter entry.

New submission from Mark Shannon : On entering the interpreter (_PyEval_EvalFrameDefault) we need to check for tracing in order to record the call. However, we don't do this cleanly resulting in slow dispatch to the non-quickened instruction on every call/next. -- assignee

[issue44826] Specialize STORE_ATTR using PEP 659 machinery.

Change by Mark Shannon : -- pull_requests: +26193 pull_request: https://github.com/python/cpython/pull/27708 ___ Python tracker <https://bugs.python.org/issue44

[issue44338] Port LOAD_GLOBAL to adaptive interpreter

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

[issue44207] Add a version number to Python functions

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

[issue44821] Instance dictionaries should be created eagerly

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

[issue44826] Specialize STORE_ATTR using PEP 659 machinery.

Mark Shannon added the comment: New changeset ac75f6bdd4748b3378dd321f862d13aa1898f77a by Mark Shannon in branch 'main': bpo-44826: Specialize STORE_ATTR (GH-27590) https://github.com/python/cpython/commit/ac75f6bdd4748b3378dd321f862d13aa1898f77a

[issue44840] Nested if/else gets phantom else trace again (3.10)

Change by Mark Shannon : -- pull_requests: +26161 pull_request: https://github.com/python/cpython/pull/27673 ___ Python tracker <https://bugs.python.org/issue44

[issue44840] Nested if/else gets phantom else trace again (3.10)

Mark Shannon added the comment: New changeset b854557b49083d8625a433eb36aacb0c87d67c52 by Mark Shannon in branch 'main': bpo-44840: Compiler: Move duplication of exit blocks with no line numbers to after CFG optimization. (GH-27656) https://github.com/python/cpython/commit

[issue44840] Nested if/else gets phantom else trace again (3.10)

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

[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

[issue44821] Instance dictionaries should be created eagerly

Mark Shannon added the comment: New changeset cee67fa66129b5d1db5c8aa3884338f82f0da3de by Mark Shannon in branch 'main': bpo-44821: Eagerly assign __dict__ for new objects. (GH-27589) https://github.com/python/cpython/commit/cee67fa66129b5d1db5c8aa3884338f82f0da3de

[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

[issue44826] Specialize STORE_ATTR using PEP 659 machinery.

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

[issue44821] Instance dictionaries should be created eagerly

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

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