[issue44298] 3.10.0b2 traces with-exit before the break that caused the exit

Mark Shannon added the comment: For context, this behavior was introduced in https://bugs.python.org/issue43933 -- ___ Python tracker <https://bugs.python.org/issue44

[issue44298] 3.10.0b2 traces with-exit before the break that caused the exit

Mark Shannon added the comment: Why this occurs: with cm: A break translates to something like: ex = cm.__exit__; cm.__enter__() # with cm A ex(...) goto loop_end # break So, the break is traced after the exit call. However, this doesn't seem consistent wit

[issue44298] 3.10.0b2 traces with-exit before the break that caused the exit

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

[issue44298] 3.10.0b2 traces with-exit before the break that caused the exit

Mark Shannon added the comment: New changeset 937cebc93b4922583218e0cbf0a9a14705a595b2 by Mark Shannon in branch 'main': bpo-44298: Fix line numbers for early exits in with statements. (GH-26513) https://github.com/python/cpython/commit/937cebc93b4922583218e0cbf0a9a1

[issue44298] 3.10.0b2 traces with-exit before the break that caused the exit

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

[issue44308] Raw Strings lack parody

Mark Dickinson added the comment: > But there's no builtin function for r'foo\bar' that gives you 'foo\\bar'. I'm confused about what's being requested here. r'foo\bar' and 'foo\\bar' are different source code representations of

[issue44308] Raw Strings lack parody

Mark Dickinson added the comment: Sorry, I missed the definition of f in the last message. Trying again: >>> def f(x): return x ... >>> f(r'foo\bar') == 'foo\\bar' True -- ___ Python tracke

[issue44308] Raw Strings lack parody

Mark Dickinson added the comment: Ah, I think I see: you want a function that turns the string "foo\bar" into "foo\\bar". Even if this were a good idea, I don't think it's feasible to do it in a non-surprising way. For example, given such a function f, wha

[issue28937] str.split(): allow removing empty strings (when sep is not None)

Mark Bell added the comment: Andrei: That is a very interesting observation, thank you for pointing it out. I guess your example / argument also currently applies to whitespace separation too. For example, if we have a whitespace separated string with contents: col1 col2 col3 a b c x y z

[issue28937] str.split(): allow removing empty strings (when sep is not None)

Mark Bell added the comment: > Instead, the discussion was focused on removing *all* empty strings from the > result. I imagine that the discussion focussed on this since this is precisely what happens when sep=None. For example, 'a b c ​'.split() == ['a'

[issue44332] For Loop temporary variable scope should be local to For loop

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

[issue44258] Support PEP 515 for Fraction's initialization from string

Mark Dickinson added the comment: New changeset 89e50ab36fac6a0e7f1998501f36fcd2872a6604 by Sergey B Kirpichev in branch 'main': bpo-44258: support PEP 515 for Fraction's initialization from string (GH-26422) https://github.com/python/cpython/commit/89e50ab36fac6a0e7f1998501

[issue44258] Support PEP 515 for Fraction's initialization from string

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

[issue42349] Compiler front-end produces a broken CFG

Mark Shannon added the comment: Basic blocks have only a single exit, at the end. https://en.wikipedia.org/wiki/Basic_block If the devguide says otherwise it is wrong. -- ___ Python tracker <https://bugs.python.org/issue42

[issue44187] Implement infrastructure for quickening and specializing

Mark Shannon added the comment: New changeset 001eb520b5757294dc455c900d94b7b153de6cdd by Mark Shannon in branch 'main': bpo-44187: Quickening infrastructure (GH-26264) https://github.com/python/cpython/commit/001eb520b5757294dc455c900d94b7

[issue44337] Port LOAD_ATTR to adaptive interpreter

New submission from Mark Shannon : Port the implementation of LOAD_ATTR to the new adaptive interpreter -- messages: 395271 nosy: Mark.Shannon priority: normal severity: normal status: open title: Port LOAD_ATTR to adaptive interpreter ___ Python

[issue44338] Port LOAD_GLOBAL to adaptive interpreter

New submission from Mark Shannon : Port the implementation of LOAD_GLOBAL to the new adaptive interpreter Once this and https://bugs.python.org/issue44337 are implemented we can remove the old opcache. -- messages: 395272 nosy: Mark.Shannon priority: normal severity: normal status

[issue44339] Discrepancy between math.pow(0.0, -inf) and 0.0**-inf

New submission from Mark Dickinson : For floats x and y, x ** y and math.pow(x, y) mostly agree. There are three points of difference: 1. if x is finite and negative and y is finite and non-integral, then x ** y returns a complex number, while math.pow(x, y) raises ValueError 2. for cases

[issue44339] Discrepancy between math.pow(0.0, -inf) and 0.0**-inf

Change by Mark Dickinson : -- components: +Library (Lib) type: -> enhancement ___ Python tracker <https://bugs.python.org/issue44339> ___ ___ Python-bugs-lis

[issue44339] Discrepancy between math.pow(0.0, -inf) and 0.0**-inf

Mark Dickinson added the comment: > What about math.pow(0.0, -1.0)? Should it return -inf or raise > ZeroDivisionError? Neither: it should raise ValueError, as it does now. This matches IEEE 754 along with the math module's mapping of IEEE 754 floating-point exceptions to Python

[issue44337] Port LOAD_ATTR to adaptive interpreter

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

[issue43693] Logically merge cell and locals array. They are already contiguous in memory

Mark Shannon added the comment: Pablo, Is there a bpo issue for the buildbot failures on Windows? The failures I've been seeing are C stack overflows. Long term, I expect to fix it by decoupling the C and Python stacks. In the short term I have a couple of changes that might get it wo

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

Mark Dickinson added the comment: [Dennis] > I think the relevant property is that the exponent is not an integer Yep: the delegation to complex pow kicks in after handling infinities and nans, and only for strictly negative base (-0.0 doesn't count as negative for this purpose)

[issue44339] Discrepancy between math.pow(0.0, -inf) and 0.0**-inf

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

[issue44346] Fraction constructor may accept spaces around '/'

Mark Dickinson added the comment: > I was surprised to realize `complex` doesn't accept '2 + 3j' See previous discussion in #9574. -- nosy: +mark.dickinson ___ Python tracker <https://bugs.

[issue44357] Add math.cbrt() function: Cube Root

Mark Dickinson added the comment: +1. This is part of C99, so if it's also supported by Visual Studio, then this seems like a no-brainer. If it's _not_ also supported by Visual Studio, or if there are implementations that have serious numerical problems (as was the case with fma)

[issue44357] Add math.cbrt() function: Cube Root

Mark Dickinson added the comment: BTW, to forestall questions about adding cmath.cbrt: it's not obvious how to extend the real cube root function to a complex cube root, so it might make sense to wait for actual use-cases before doing so. The issue is that the most natural way to def

[issue44363] Likely false positive for address sanitizer after fork

New submission from Mark Shannon : Running the buildbot for https://github.com/python/cpython/pull/26595 results in failures: https://buildbot.python.org/all/#/builders/581/builds/63 Which claim that the address calculation in `LOAD_ATTR_MODULE` is out of bounds. The tests pass with an added

[issue44348] test_exceptions.ExceptionTests.test_recursion_in_except_handler stack overflow on Windows debug builds

Change by Mark Shannon : -- nosy: +Mark.Shannon nosy_count: 9.0 -> 10.0 pull_requests: +25208 pull_request: https://github.com/python/cpython/pull/26623 ___ Python tracker <https://bugs.python.org/issu

[issue44363] Likely false positive for address sanitizer after fork

Mark Shannon added the comment: If I run the following on main ./configure --with-address-sanitizer make clean make -j12 test I get 22 failures. So something is broken. test_lib2to3 does fork; at least it does when I run it under gdb

[issue44357] Add math.cbrt() function: Cube Root

Mark Dickinson added the comment: > Perhaps because it is so easy to write x**(1/3), and if you want a real root > of negative argument, it is -(-x)**(1/3). I consider `x**(1/3)` to be a trap and a bug magnet: many people won't realise that the correct spelling for their s

[issue44357] Add math.cbrt() function: Cube Root

Mark Dickinson added the comment: There's also a decent chance that a libm implementation of cbrt will be correctly rounded, while `x**(1/3)` is highly unlikely to be so. -- ___ Python tracker <https://bugs.python.org/is

[issue44206] Add a version number to dict keys.

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

[issue44357] Add math.cbrt() function: Cube Root

Mark Dickinson added the comment: @Victor: Yep, the name is pretty standard. Not just C, but JavaScript, Java, R, and likely a lot of other languages that I haven't checked. -- ___ Python tracker <https://bugs.python.org/is

[issue44187] Implement infrastructure for quickening and specializing

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

[issue44363] Address sanitizer (gcc version) is generating false positives

Mark Shannon added the comment: I still get quite a few failures on the main branch. It seems like ceval.c:1600 upsets the sanitizer, at least for gcc. There isn't anything wrong with that line, but as I plan to change it anyway I guess it doesn't matter: https://github.com/pyth

[issue44357] Add math.cbrt() function: Cube Root

Mark Dickinson added the comment: If we *really* wanted to bikeshed on the name, back in 1991 Kahan wrote: > Perhaps the last problem is the hardest: choosing the program's name. Ideally > it should need no explanation, but a limitation upon its length may preclude > that.

[issue44364] Add non integral tests for `sqrt()`

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

[issue44363] Address sanitizer (gcc version) is generating false positives

Mark Shannon added the comment: What commit are you running that on? -- ___ Python tracker <https://bugs.python.org/issue44363> ___ ___ Python-bugs-list mailin

[issue44363] Address sanitizer (gcc version) is generating false positives

Mark Shannon added the comment: This line seems to be responsible for most of the failures: https://github.com/python/cpython/blob/main/Objects/frameobject.c#L985 Which does appear to be a true positive. -- ___ Python tracker <ht

[issue44187] Implement infrastructure for quickening and specializing

Mark Shannon added the comment: No, this is done -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Mark Dickinson added the comment: See also #11986, which this report is essentially a duplicate of. I think it may be time to implement `math.ieee754_total_order` (after suitable bikeshedding about the name), so that one can do sorted(my_list_of_floats, key=math.ieee754_total_order) and

[issue44337] Port LOAD_ATTR to adaptive interpreter

Mark Shannon added the comment: New changeset e117c0283705943189e6b1aef668a1f68f3f00a4 by Mark Shannon in branch 'main': bpo-44337: Port LOAD_ATTR to PEP 659 adaptive interpreter (GH-26595) https://github.com/python/cpython/commit/e117c0283705943189e6b1aef668a1

[issue44348] test_exceptions.ExceptionTests.test_recursion_in_except_handler stack overflow on Windows debug builds

Mark Shannon added the comment: New changeset 54cb63863f19a7c64d9a3a5fd97bdfc0dd7ab374 by Mark Shannon in branch 'main': bpo-44348: Move trace-info to thread-state (GH-26623) https://github.com/python/cpython/commit/54cb63863f19a7c64d9a3a5fd97bdf

[issue44363] Address sanitizer (gcc version) is generating false positives

Mark Shannon added the comment: It looks like I've been a bit unfair to the address sanitizer. It does appear to produce incorrect locations sometimes, but that's not really a false positive and the reports are generally useful. --

[issue44313] Generate LOAD_ATTR+CALL_FUNCTION instead of LOAD_METHOD+CALL_METHOD for imports

Mark Shannon added the comment: Yes. Simpler is good. I think it will also be better for performance: In general, we don't know what X is in `from Y import X`. It could be a module or anything else. However, if we are accessing an attribute it is quite likely to be a module or class

[issue44337] Port LOAD_ATTR to adaptive interpreter

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

[issue44338] Port LOAD_GLOBAL to adaptive interpreter

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

[issue44363] Address sanitizer (gcc version) is generating false positives

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

[issue44364] Add non integral tests for `sqrt()`

New submission from Mark Dickinson : New changeset 90cd4330329a99e52f7141db5e0a469d30088e66 by Ajith Ramachandran in branch 'main': bpo-44364:Add non integral tests for `sqrt()` (#26625) https://github.com/python/cpython/commit/90cd4330329a99e52f7141db5e0a46

[issue44364] Add non integral tests for `sqrt()`

Change by Mark Dickinson : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44364> ___ ___ Pyth

[issue44357] Add math.cbrt() function: Cube Root

Mark Dickinson added the comment: New changeset ac867f10b49322e25f34d2d8abd8e63c86834750 by Ajith Ramachandran in branch 'main': bpo-44357:Add `math.cbrt()` function: Cube Root (GH-26622) https://github.com/python/cpython/commit/ac867f10b49322e25f34d2d8abd8e6

[issue44357] Add math.cbrt() function: Cube Root

Mark Dickinson added the comment: All done; closing. Thank you for the contribution! -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue44376] Improve performance of integer exponentiation

Mark Dickinson added the comment: I can't reproduce this on my Mac laptop (using Python builds from MacPorts). Numbers for both x**2 and x*x are fairly stable across Python 3.2 to Python 3.10. There's some variation, but nothing close to the same extent that Steven is seeing. H

[issue44364] Add non integral tests for `sqrt()`

Mark Dickinson added the comment: > 2921 is the smallest integers for which math.sqrt(x) > x**0.5 This is platform-dependent. On my machine, for example, `math.sqrt(2921) == 2921**0.5` returns `True`. I don't see a lot of value in additional tests here; we're only wrappin

[issue40320] Add ability to specify instance of contextvars context to Task() & asyncio.create_task()

Change by Mark Gordon : -- keywords: +patch nosy: +msg555 nosy_count: 3.0 -> 4.0 pull_requests: +25251 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26664 ___ Python tracker <https://bugs.python.org/i

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Mark Dickinson added the comment: > We should consider biting the bullet and revising the default NaN sort order. If we went that route, I think we wouldn't need to consider payload or identity. We could just do: NaN < NaN -> False NaN < non-NaN -&g

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Mark Dickinson added the comment: > That is, do we want NaNs to sort to the beginning of the list, or the end? FWIW, NumPy chooses to sort NaNs to the end of the list: https://numpy.org/doc/stable/reference/generated/numpy.sort.html -- ___ Pyt

[issue36027] Support negative exponents in pow() where a modulus is specified.

Change by Mark Dickinson : -- pull_requests: +25277 pull_request: https://github.com/python/cpython/pull/26690 ___ Python tracker <https://bugs.python.org/issue36

[issue44400] Propose random.randbool()

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

[issue44339] Discrepancy between math.pow(0.0, -inf) and 0.0**-inf

Mark Dickinson added the comment: New changeset 4a42cebf6dd769e2fa4e234a9e91093b3ad1cb63 by Mark Dickinson in branch 'main': bpo-44339: Fix math.pow corner case to comply with IEEE 754 (GH-26606) https://github.com/python/cpython/commit/4a42cebf6dd769e2fa4e234a9e9109

[issue44339] Discrepancy between math.pow(0.0, -inf) and 0.0**-inf

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

[issue36027] Support negative exponents in pow() where a modulus is specified.

Change by Mark Dickinson : -- pull_requests: +25287 pull_request: https://github.com/python/cpython/pull/26703 ___ Python tracker <https://bugs.python.org/issue36

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: @realead > This change makes life harder for people trying to get sane behavior with > sets [...] Yes, code that assumes that all NaNs have the same hash value will need to change. But that doesn't seem unreasonable for objects that are already

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: @Serhiy: can this be closed again? Does GH-26679 need to be backported to the 3.10 branch? -- ___ Python tracker <https://bugs.python.org/issue43

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: > Does this change need to be mentioned in What's New? Yes, I think so, given that it's a change to documented behavior. It's also something that third party packages (like NumPy) potentially ne

[issue44338] Port LOAD_GLOBAL to adaptive interpreter

Mark Shannon added the comment: New changeset eecbc7c3900a7f40d8498b151db543a202c72f74 by Mark Shannon in branch 'main': bpo-44338: Port LOAD_GLOBAL to PEP 659 adaptive interpreter (GH-26638) https://github.com/python/cpython/commit/eecbc7c3900a7f40d8498b151db543

[issue44337] Port LOAD_ATTR to adaptive interpreter

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

[issue44417] bytecode<>line number mapping and f_lasti seem wrong in 3.10.0b2

Mark Shannon added the comment: What does "seem wrong" mean? What exactly is the problem? -- ___ Python tracker <https://bugs.python.org/issue44417> ___ __

[issue44283] Add jump table for certain safe match-case statements

Mark Shannon added the comment: This is going in the wrong direction. Rather than add more complex instructions for use only by pattern matching, we need to simplify the individual operations and re-use existing instructions. That way pattern matching can benefit from the general performance

[issue43475] Worst-case behaviour of hash collision with float NaN

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

[issue44425] 'dirty' added to sys.version on Linux and Mac source builds depending on git version

New submission from Mark Final : Hi, We build Python 3.7 from source in-house for Windows, Linux and macOSX. It's been noticed that 'dirty' has been appended to sys.version in our builds, even though the source tree has not been modified from a git clone. This only happen

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: Hmm. It's probably not the best name, and we can certainly change it. But I'm a bit confused by the error message: `complex` isn't a keyword in either C or C++, so I'm not sure why Sphinx thinks it is. -- n

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: As a test, gcc and clang both seem happy to treat this as valid C. I think Sphinx is wrong to reject this. mdickinson@mirzakhani Desktop % cat test.c typedef struct { double real; double imag; } Py_complex; Py_complex _Py_c_neg(Py_complex complex

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: New changeset 1d10bf0bb9409a406c56b0de8870df998637fd0f by Mark Dickinson in branch 'main': bpo-43475: Add what's new entry for NaN hash changes (GH-26725) https://github.com/python/cpython/commit/1d10bf0bb9409a406c56b0de8

[issue43475] Worst-case behaviour of hash collision with float NaN

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

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

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

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: New changeset 8d0b2ca493e236fcad8709a622c1ac8ad29c372d by Mark Dickinson in branch '3.10': [3.10] bpo-43475: Add what's new entry for NaN hash changes (GH-26725) (GH-26743) https://github.com/python/cpython/commit/8d0b2ca493e236fcad8709a62

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: I think this can be closed now. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue44357] Add math.cbrt() function: Cube Root

Change by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker <https://bugs.python.org/issue44357> ___ ___ Python-bugs-list mailing list Un

[issue38211] clean up type_init()

Mark Shannon added the comment: New changeset ab030d6f9d73e7f6c2213c2e308d1ceb04761485 by Sergey Fedoseev in branch 'main': bpo-38211: Clean up type_init() (GH-16257) https://github.com/python/cpython/commit/ab030d6f9d73e7f6c2213c2e308d1ceb04761485 -- nosy: +Ma

[issue44337] Port LOAD_ATTR to adaptive interpreter

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

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: New changeset 7247f6f433846c6e37308a550e8e5eb6be379856 by Mark Dickinson in branch 'main': bpo-44426: Use of 'complex' as a C variable name confuses Sphinx; change it to 'num'. (GH-26744) https://gi

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: New changeset 686c6f303a6e9e54b50401be0ae3dc6aa2fcf05a by Miss Islington (bot) in branch '3.9': bpo-44426: Use of 'complex' as a C variable name confuses Sphinx; change it to 'num'. (GH-26744) (GH-26761) https://gi

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: New changeset c689e0a7e2a25621da82f22cc64d089eae05e753 by Miss Islington (bot) in branch '3.10': bpo-44426: Use of 'complex' as a C variable name confuses Sphinx; change it to 'num'. (GH-26744) (GH-26760) https://gi

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: > and we can certainly change it Done. Closing here, but I've opened a Sphinx issue at https://github.com/sphinx-doc/sphinx/issues/9354 -- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open ->

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: Thanks. That one's a genuine keyword. Looks like what we probably need to do is get a list of all these errors, so that they can all be fixed at once. Presumably running without the "-W" flag would m

[issue43693] Logically merge cell and locals array. They are already contiguous in memory

Change by Mark Shannon : -- assignee: Mark.Shannon -> eric.snow ___ Python tracker <https://bugs.python.org/issue43693> ___ ___ Python-bugs-list mai

[issue44442] Globals (and presumably builtins) are cleared premuturely in FrameObject

New submission from Mark Shannon : When calling frame.clear(), the globals (and builtins) are cleared. This is not the case in 3.10. We should restore the 3.10 behavior, as there is no reason not to. Victor, you've mentioned this problem. Did you have a specific example I can add as a

[issue44442] Globals (and presumably builtins) are cleared premuturely in FrameObject

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

[issue44442] Globals (and presumably builtins) are cleared premuturely in FrameObject

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

[issue44442] Globals (and presumably builtins) are cleared premuturely in FrameObject

Mark Shannon added the comment: No problem, I've added a simple test. -- stage: patch review -> ___ Python tracker <https://bugs.python.org/issue2> ___

[issue44032] Function locals and evaluation stack should be stored in a contiguous, per-thread stack

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

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: Thanks; this looks like an easy fix, then. No time right now, but I'll aim to get to it at some point before the end of the weekend, if no-one beats me to it. -- ___ Python tracker <https://bugs.py

[issue44032] Function locals and evaluation stack should be stored in a contiguous, per-thread stack

Mark Shannon added the comment: New changeset 0982ded179f280176868c1c4eccf77bf70687816 by Mark Shannon in branch 'main': bpo-44032: Move pointer to code object from frame-object to frame specials array. (GH-26771) https://github.com/python/cpyt

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

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

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

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

[issue44426] Docs fail to build with Sphinx 4 due to Invalid C declaration

Mark Dickinson added the comment: Fixed in GH-26798 (not yet merged). With that change, the documentation builds cleanly for me with Python 3.9.5 / Sphinx 4.0.2 / blurb 1.0.8 / python-docs-theme 2021.5, using the command $ python -m sphinx -b html -W . build/html

[issue35714] Document that the null character '\0' terminates a struct format spec

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

[issue6871] decimal.py: more format issues

Mark Dickinson added the comment: Eric: any thoughts on this? It's looking like a "won't fix" to me. Regardless of what we think the "right" thing to do is, making the float behaviour stricter would be a backwards compatibility break, and relaxing the Dec

<    29   30   31   32   33   34   35   36   37   38   >