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

Mark Dickinson added the comment: Agreed that "of the same type" part is confusing. I suspect the intended meaning was that the operation *expects* both arguments to have the same type, so if the actual arguments have different types then they have to be coerced to a c

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

Mark Dickinson added the comment: > the confusion that it can cause when there is a mismatch between the > interactive interpreter and noninteractive execution I've witnessed similar confusion when teaching, using IPython. After discovering that you can do In [1]: import pandas

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

Mark Dickinson added the comment: No, no plans. There are tradeoffs here - the extra speed comes at the expense of increased maintenance burden. (It's certainly much harder to make minor changes and fixes to the decimal module now that it's written in C.) -- nosy: +mark.dickinson

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

Mark Dickinson added the comment: and the related issue: https://bugs.python.org/issue1446372 -- ___ Python tracker <https://bugs.python.org/issue44603> ___ ___

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

Mark Dickinson added the comment: Related 2005 python-dev discussion: https://mail.python.org/archives/list/python-...@python.org/thread/VNGY2DLML4QJUXE73JLVBIH5WFBZNIKG/ -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.

[issue44593] _randbelow_with_getrandbits may request an unnecessary random bit

Change by Mark Dickinson : -- resolution: -> duplicate superseder: -> _randbelow_with_getrandbits function inefficient with powers of two ___ Python tracker <https://bugs.python.org/i

[issue44593] _randbelow_with_getrandbits may request an unnecessary random bit

Mark Dickinson added the comment: See #37000 for previous discussion. -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue44593> ___ ___

[issue44550] Spam

Change by Mark Dickinson : -- title: DIGITAL CLASSROOM -> Spam ___ Python tracker <https://bugs.python.org/issue44550> ___ ___ Python-bugs-list mailing list Un

[issue44547] fraction.Fraction does not implement __int__.

Mark Dickinson added the comment: Thanks, that's helpful. I guess what you _really_ want there is a duck-typed "tell me whether this value is integral and if so give me the corresponding Python int", but that's not currently easily available, so I suppose x == int(x) is the next-

[issue44547] fraction.Fraction does not implement __int__.

Mark Dickinson added the comment: > As another data point, complex supporting __int__ is a little bit of an > oddity, since all that __int__ method does is raise a TypeError. This was fixed in 3.10: #41974 -- ___ Python tracker

[issue44547] fraction.Fraction does not implement __int__.

Mark Dickinson added the comment: > Maybe typing.SupportsIndex Apologies: that already exists, of course. It was introduced in #36972. -- ___ Python tracker <https://bugs.python.org/issu

[issue44547] fraction.Fraction does not implement __int__.

Mark Dickinson added the comment: I'm actually struggling to think of situations where typing.SupportsInt would be useful in its current form: if I'm writing a function that wants to do a duck-typed acceptance of integer-like things (for example because I want my function to work with NumPy

[issue44547] fraction.Fraction does not implement __int__.

Mark Dickinson added the comment: FWIW, there's some history here: there's a good reason that fractions.Fraction didn't originally implement __int__. Back in the Bad Old Days, many Python functions that expected an integer would accept anything whose type implemented __int__ instead

[issue44546] spam

Change by Mark Dickinson : -- Removed message: https://bugs.python.org/msg396825 ___ Python tracker <https://bugs.python.org/issue44546> ___ ___ Python-bug

[issue44546] spam

Change by Mark Dickinson : -- stage: -> resolved status: open -> closed title: ASSESSMENT TOOLS -> spam ___ Python tracker <https://bugs.python.or

[issue44545] spam

Change by Mark Dickinson : -- Removed message: https://bugs.python.org/msg396822 ___ Python tracker <https://bugs.python.org/issue44545> ___ ___ Python-bug

[issue44545] spam

Change by Mark Dickinson : -- Removed message: https://bugs.python.org/msg396824 ___ Python tracker <https://bugs.python.org/issue44545> ___ ___ Python-bug

[issue44545] spam

Change by Mark Dickinson : -- stage: -> resolved status: open -> closed title: ASSESSMENT TOOLS -> spam ___ Python tracker <https://bugs.python.or

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

Mark Dickinson added the comment: FWIW, the relevant change seems to be this one: https://github.com/sphinx-doc/sphinx/pull/7155 -- ___ Python tracker <https://bugs.python.org/issue16

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

Mark Dickinson added the comment: I suspect the difference is due to a change in the way that Sphinx handles the py:method directive: the rst source for `pathlib.Path.touch` hasn't changed between 3.9 and 3.10, but the 3.9 docs are built with Sphinx 2.4.4, while the 3.10 docs are built

[issue44536] wrong output of np.lcm.reduce(*awg)

Mark Dickinson added the comment: It looks as though you're reporting an issue with NumPy; this tracker is for the Python core language, which doesn't include NumPy. For NumPy bugs, use the NumPy bug tracker at https://github.com/numpy/numpy/issues. (Though I don't think this _is_ a NumPy

[issue44508] asyncio: document failure mode for loop.call_soon_threadsafe

New submission from Mark Dickinson : `loop.call_soon_threadsafe` raises `RuntimeError` when the event loop has been closed, but that fact doesn't seem to be documented. It would be useful to document it so that that it's clear that that behaviour is part of the API, and can be depended

[issue44470] 3.11 docs.python.org in Polish not English?

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

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

Mark Dickinson added the comment: Thanks! Closing. -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue44426> ___ ___ Python-bugs-lis

[issue44488] ERROR: No matching distribution found for kivy

Mark Dickinson added the comment: I'd suggest reporting this on the kivy bug tracker: https://github.com/kivy/kivy This tracker is for the Python core language, and this doesn't look like a problem caused by a bug in Python. -- nosy: +mark.dickinson resolution: -> third party st

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

Mark Dickinson added the comment: > Perhaps we should just borrow from the documentation for the power operator, > which says [...] That sounds good to me. -- ___ Python tracker <https://bugs.python.org/i

[issue44470] 3.11 docs.python.org in Polish not English?

Mark Dickinson added the comment: The bug here is that https://docs.python.org/3.11/library/parser.html is visible at all, given that the parser module no longer exists in 3.10 or 3.11. @Samuel: Do you see this on any other documentation nodes, or just on parser.html? I can reproduce

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

Mark Dickinson added the comment: I think this should be good now. -- resolution: -> fixed stage: patch review -> resolved status: open -> pending ___ Python tracker <https://bugs.python.or

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

Mark Dickinson added the comment: New changeset 533bff4e9fe221a7c9cf12795fd2d002e87bfa6a by Miss Islington (bot) in branch '3.9': bpo-44426: Fix use of the C keyword 'default' as a variable name (GH-26798) (GH-26805) https://github.com/python/cpython/commit

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

Mark Dickinson added the comment: New changeset 139c5778c26aaf25b51fcfabd88c99ba728beaea by Miss Islington (bot) in branch '3.10': bpo-44426: Fix use of the C keyword 'default' as a variable name (GH-26798) (GH-26804) https://github.com/python/cpython/commit

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

Mark Dickinson added the comment: New changeset 291848195f85e23c01adb76d5a0ff9c6eb7f2614 by Mark Dickinson in branch 'main': bpo-44426: Fix use of the C keyword 'default' as a variable name (GH-26798) https://github.com/python/cpython/commit/291848195f85e23c01adb76d5a0ff9c6eb7f2614

[issue29282] Fused multiply-add: proposal to add math.fma()

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

[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 Decimal behav

[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

[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

[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

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

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

[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 make t

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

[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://github.com/python/cpython/commit

[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://github.com/python/cpython/commit

[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://github.com/python/cpython/commit

[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

[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

[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/8d0b2ca493e236fcad8709a622c1ac8ad29c372d

[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

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

[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/1d10bf0bb9409a406c56b0de8870df998637fd0f

[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

[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. -- nosy: +mark.dickinson

[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

[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 need to be aw

[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: @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 cons

[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

[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

[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/4a42cebf6dd769e2fa4e234a9e91093b3ad1cb63

[issue44400] Propose random.randbool()

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

[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

[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

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

[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 wrapping the lib

[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. Here are my

[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

[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/ac867f10b49322e25f34d2d8abd8e63c86834750

[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

[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/90cd4330329a99e52f7141db5e0a469d30088e66

[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

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

[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. Altho

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

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

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

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

[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) we'll need

[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.python.org/issu

[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

[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) and

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

[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

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

[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

[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/89e50ab36fac6a0e7f1998501f36fcd2872a6604

[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

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

[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 tracker <https://bugs.

[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 the exact same string (same type, same contents),

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Change by Mark Dickinson : -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44267> ___ ___

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Mark Dickinson added the comment: > Regarding mail thread: I don't think that following the PEP will slow down string conversion. Sorry, I just don't think it's worth re-opening this discussion; Stefan Krah had good reasons (not just speed) to avoid implementing a precise interpretat

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Mark Dickinson added the comment: > Well, then I something misunderstood in PEP 0 Yep, you're absolutely right. I should have said "after the PEP is final", not "after the PEP is accepted". PEP 515 was marked final on April 28th, 2017. > The current behaviour

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Mark Dickinson added the comment: > If this is not a bug - it should be adjusted Standards Track PEPs are historical documents; it's quite common that an actual implementation ends up diverging from a PEP in small ways after the PEP is accepted, and we don't usually do post-hoc upda

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Mark Dickinson added the comment: There was some discussion of this on the python-dev mailing list at the time - see https://mail.python.org/pipermail/python-dev/2016-March/143556.html and the surrounding thread. It's probably best left alone

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

Mark Dickinson added the comment: > How about '1_/_2'? I'd rather keep it consistent with the rules for int: that is, if I split on `'/'`, I'd expect the pieces to be parseable by `int`. As for spaces around the `/`, let's make that a separate is

[issue35427] logging UnicodeDecodeError from undecodable strftime output

Mark Dickinson added the comment: Agreed. Thank you! -- stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/i

[issue35296] Install Include/internal/ header files

Change by Mark Dickinson : -- title: Python -> Install Include/internal/ header files versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issu

[issue35296] Python

Change by Mark Dickinson : -- Removed message: https://bugs.python.org/msg394672 ___ Python tracker <https://bugs.python.org/issue35296> ___ ___ Python-bug

[issue35296] Python

Change by Mark Dickinson : -- Removed message: https://bugs.python.org/msg394671 ___ Python tracker <https://bugs.python.org/issue35296> ___ ___ Python-bug

[issue32596] Lazy import concurrent.futures.process and thread

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

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

Mark Dickinson added the comment: You say "for testing purposes only", but I'd add "for debugging" to the list of use-cases, having just spent a few hours trying to understand why I was getting a particular PySide2 "Internal C++ object already deleted.&quo

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