[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

[issue45134] Protocol dealloc not called if Server is closed

New submission from Mark : If I create_server server_coro = loop.create_server( lambda: self._protocol_factory(self), sock=sock, ssl=ssl) server = loop.run_until_complete(server_coro) Then connect and disconnect a client the protocol connection lost and dealloc are called

[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

[issue39320] Handle unpacking of */** arguments and rvalues in the compiler

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

[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6

Mark Lierley added the comment: I am also experiencing this issue. I have an M1 Macbook Air running MaOS Monterey Version 12.0 Beta (21A5304g) with a fresh install of Python 3.9.6. When attempting to save or open anything from either the editor or console window I get the following error

[issue45020] Freeze all modules imported during startup.

Mark Shannon added the comment: I don't recall, but... You can't modify any builtin modules. Freezing modules effectively makes them builtin from a user's perspective. There are plenty of modules that can't be modified: >>> sys.builtin_module_names ('_abc', '_ast', '_codecs', '_co

[issue44826] Specialize STORE_ATTR using PEP 659 machinery.

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

[issue44945] Specialize BINARY_ADD using PEP 659 machinery.

Change by Mark Shannon : -- stage: resolved -> ___ Python tracker <https://bugs.python.org/issue44945> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue44945] Specialize BINARY_ADD using PEP 659 machinery.

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

[issue44945] Specialize BINARY_ADD using PEP 659 machinery.

Mark Shannon added the comment: New changeset d3eaf0cc5b311ad023fd13e367f817d528403306 by Mark Shannon in branch 'main': bpo-44945: Specialize BINARY_ADD (GH-27967) https://github.com/python/cpython/commit/d3eaf0cc5b311ad023fd13e367f817d528403306

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

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

[issue44990] Change layout of frames back to specials-locals-stack (from locals-specials-stack)

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

[issue33092] The bytecode for f-string formatting is inefficient.

Mark Shannon added the comment: No significant change in performance https://gist.github.com/markshannon/34a780d65e69b5a573a83f3fdb0139aa I think this merely indicates that there are little to no f-strings in the pyperformance benchmark suite

[issue44945] Specialize BINARY_ADD using PEP 659 machinery.

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

[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

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

Mark Shannon added the comment: New changeset 15d50d7ed8afd3ab26b00210b5b4feaaadd5af51 by Mark Shannon in branch 'main': bpo-44946: Streamline operators and creation of ints for common case of single 'digit'. (GH-27832) https://github.com/python/cpython/commit

[issue44990] Change layout of frames back to specials-locals-stack (from locals-specials-stack)

Mark Shannon added the comment: New changeset f9242d50b18572ef0d584a1c815ed08d1a38e4f4 by Mark Shannon in branch 'main': bpo-44990: Change layout of evaluation frames. "Layout B" (GH-27933) https://github.com/python/cpython/commit/f9242d50b18572ef0d584a1c815ed0

[issue44990] Change layout of frames back to specials-locals-stack (from locals-specials-stack)

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

[issue7057] tkinter doc: more 3.x updates

Mark Roseman added the comment: yes this should be closed.. with latest doc updates, most of these are no longer at all relevant -- nosy: +markroseman ___ Python tracker <https://bugs.python.org/issue7

[issue44990] Change layout of frames back to specials-locals-stack (from locals-specials-stack)

New submission from Mark Shannon : The two plausible layouts from evaluation stack frames are described here: https://github.com/faster-cpython/ideas/issues/31#issuecomment-844263795 We opted for layout A, although it is a bit more complex to manage and slightly more expensive in terms

[issue42560] Improve Tkinter Documentation

Mark Roseman added the comment: Łukasz, thank you very much for your help with getting these changes merged in! I hope others will chime in with suggestions and/or edits to the newer or substantially revised sections. There is most definitely lots of room for improvement. One specific

[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

[issue44964] Semantics of PyCode_Addr2Line() changed

Mark Shannon added the comment: It is not `PyCode_Addr2Line()` that has changed, but `frame->f_lasti`. If you call `PyCode_Addr2Line(frame->f_code, 8)` in 3.9 you get the same behavior as calling `PyCode_Addr2Line(frame->f_code, 8)` in 3.10. Assuming the bytecode is

[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

[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

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