[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

On Tue, Feb 8, 2022 at 1:47 PM Guido van Rossum wrote: > > Thanks for trying it! I'm curious why it would be slower (perhaps less > locality? perhaps the ...Id... APIs have some other trick up their sleeve?) > but since it's also messier and less backwards compatible than just leaving >

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

Thanks for trying it! I'm curious why it would be slower (perhaps less locality? perhaps the ...Id... APIs have some other trick up their sleeve?) but since it's also messier and less backwards compatible than just leaving _Py_IDENTIFIER alone and just not using it, I'd say let's not spend more

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

There are problems with urllib. With hindsight, it would have been nice to do a few things differently. But that doesn't make migrating away from it any easier. This thread has mentioned several "better" alternatives -- but with the exception of 3rd party Requests, the docs don't even

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

On Fri, Feb 4, 2022 at 8:25 PM Eric Snow wrote: > On Fri, Feb 4, 2022, 16:03 Guido van Rossum wrote: >> I wonder if a better solution than that PR wouldn't be to somehow change the >> implementation of _Py_IDENTIFIER() to do that, > > Yeah, I had the same realization today. I'm going to try it

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 4:52 PM Christopher Barker wrote: > From the perspective of some that writes a lot of computational code: > > On Mon, Feb 7, 2022 at 10:25 AM Mark Dickinson wrote: > >> - Should we require the presence of NaNs in order for CPython to build? >> - Should we require IEEE 754

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

- Should we require the presence of NaNs in order for CPython to build? - Should we require IEEE 754 floating-point for CPython-the-implementation? - Should we require IEEE 754 floating-point for Python-the-language? I don't have strong opinions on the first two, but for the language definition,

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

https://www.ibm.com/docs/en/SSGH3R_16.1.0/pdf/getstart.pdf As far as reading page 3, xlclang fully supports C89/C99/C11. xlc fully supports C89/C99, and partially supports C11. On Tue, Feb 8, 2022 at 8:57 AM Brett Cannon wrote: > > > > On Mon, Feb 7, 2022 at 9:12 AM Victor Stinner wrote: >> >>

[Python-Dev] Re: RFC on PEP 675: Arbitrary Literal Strings

On Mon, Feb 7, 2022 at 3:55 PM Brett Cannon wrote: > Can I suggest adding a "Specification" section (see > https://www.python.org/dev/peps/pep-0012/#suggested-sections for the > suggested sections to have in a PEP)? > Brett: I'm sorry about this oversight. I've fixed it in

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

>From the perspective of some that writes a lot of computational code: On Mon, Feb 7, 2022 at 10:25 AM Mark Dickinson wrote: > - Should we require the presence of NaNs in order for CPython to build? > - Should we require IEEE 754 floating-point for CPython-the-implementation? > Yes, and yes,

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Tue, Feb 8, 2022 at 12:19 AM Brett Cannon wrote: > Do we have a buildbot that has a CPU or OS that can't handle IEEE-754? What > are the chances we will get one? If the answers are "none" and "slim", then > it seems reasonable to require NaN and IEEE-754. All CPU architectures of current

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

On Mon, Feb 7, 2022 at 9:12 AM Victor Stinner wrote: > Hi, > > I made a change to require C99 "NAN" constant and I'm was > asked to update the PEP 7 to clarify the C subset is needed to build > Python 3.11. > > Python 3.6 requires a subset of the C99 standard to build defined by the > PEP 7: >

[Python-Dev] Re: RFC on PEP 675: Arbitrary Literal Strings

Can I suggest adding a "Specification" section (see https://www.python.org/dev/peps/pep-0012/#suggested-sections for the suggested sections to have in a PEP)? When you first pull up the PEP it goes from "Rationale" to "Valid Locations for LiteralString". As a reader that doesn't point me at a

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

On Mon, Feb 7, 2022 at 4:56 AM Steve Dower wrote: > On 2/6/2022 4:44 PM, Christian Heimes wrote: > > If I had the power and time, then I would replace urllib with a simpler, > > reduced HTTP client that uses platform's HTTP library under the hood > > (WinHTTP on Windows, NSURLSession (?) on

[Python-Dev] RFC on PEP 675: Arbitrary Literal Strings

PEP 675 [1] introduces a supertype for precise literal string types, such as `Literal["foo"]`, called `LiteralString`. The PEP allows libraries to distinguish the type of command strings from data. Powerful, command-executing libraries try to prevent security vulnerabilities by accepting

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

On Mon, Feb 7, 2022 at 5:11 PM Victor Stinner vstin...@python.org wrote: > I made a change to require C99 "NAN" constant and I'm was > asked to update the PEP 7 to clarify the C subset is needed to build > Python 3.11. What if it was built with MSVC which is usually just C90?

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

On Mon, Feb 7, 2022 at 8:59 AM Victor Stinner wrote: > On Mon, Feb 7, 2022 at 5:48 PM Guido van Rossum wrote: > > So you're proposing to completely get rid of those three? > > I don't propose to remove them, but only call them if Python is built > in debug mode. Or remove them from the release

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 12:31 PM Gregory P. Smith wrote: > > > On Mon, Feb 7, 2022 at 11:06 AM Victor Stinner > wrote: > >> Hi Mark, >> >> Aha, good, you posted an email to python-dev, good :-) Last days, I >> was trying to collect more data about this topic, especially find >> platforms which

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 11:02 AM Victor Stinner wrote: > Hi Mark, > > Aha, good, you posted an email to python-dev, good :-) Last days, I > was trying to collect more data about this topic, especially find > platforms which *don't* support IEEE 754, before posting to > python-dev. > > Nowadays,

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 11:06 AM Victor Stinner wrote: > Hi Mark, > > Aha, good, you posted an email to python-dev, good :-) Last days, I > was trying to collect more data about this topic, especially find > platforms which *don't* support IEEE 754, before posting to > python-dev. > > Nowadays,

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

Hi Mark, Aha, good, you posted an email to python-dev, good :-) Last days, I was trying to collect more data about this topic, especially find platforms which *don't* support IEEE 754, before posting to python-dev. Nowadays, outside museums, it's hard to find computers which don't implement IEEE

[Python-Dev] Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 5:11 PM Victor Stinner wrote: > I made a change to require C99 "NAN" constant [...] There's a separate discussion topic lurking here. It's equally in need of discussion here (IMO), but it's orthogonal to the "should we require C99" discussion. I've changed the subject

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

On 2/7/2022 11:48 AM, Guido van Rossum wrote: (I still haven't gotten into the habit of building in debug mode by default, in part because it *isn't* the default when you invoke ./configure or PCbuild/build.bat.) On Windows, I have build.bat in the directory containing the repository and

[Python-Dev] Require a C compiler supporting C99 to build Python 3.11

Hi, I made a change to require C99 "NAN" constant and I'm was asked to update the PEP 7 to clarify the C subset is needed to build Python 3.11. Python 3.6 requires a subset of the C99 standard to build defined by the PEP 7: https://www.python.org/dev/peps/pep-0007/ I modified Python 3.11 to

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

On Mon, Feb 7, 2022 at 5:48 PM Guido van Rossum wrote: > So you're proposing to completely get rid of those three? I don't propose to remove them, but only call them if Python is built in debug mode. Or remove them from the release build, unless ./configure --with-assertions is used. > And

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

So you're proposing to completely get rid of those three? And you're sure that each and every single call to any of those is better off being an assert()? (I still haven't gotten into the habit of building in debug mode by default, in part because it *isn't* the default when you invoke

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

My two cents: 1. I’ve grepped ("ag-ed" acually) through all my code bases, and as noted by others, urllib.parse is used in many places. urllib.request never is, as we've been using requests or httpx instead. IMHO and for the context I'm using it (YMMV), urllib.parse is useful and should be kept

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

On Mon, Feb 7, 2022 at 5:38 PM Guido van Rossum wrote: > ISTM this is better discussed on a case-by-case basis than as a blanket > policy change. (The latter could end up causing a flood of trivial PRs from > wannabe-contributors who found and fix yet another violation of the policy, > which

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

ISTM this is better discussed on a case-by-case basis than as a blanket policy change. (The latter could end up causing a flood of trivial PRs from wannabe-contributors who found and fix yet another violation of the policy, which is both a nuisance for reviewers and a risk of introducing bugs due

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

Yes, please build it; I can't quite follow what you're getting at (probably since I don't know the Windows APIs). On Mon, Feb 7, 2022 at 4:39 AM Steve Dower wrote: > On 2/5/2022 4:09 PM, Guido van Rossum wrote: > > On Sat, Feb 5, 2022 at 5:18 AM Steve Dower > >

[Python-Dev] Python-Dev] Replace debug runtime checks in release mode, with assertions in debug mode

On 7/2/22 17:55, Victor Stinner wrote: End users should not have to pay the price of these runtime checks. Is the cost of the checks measurable and significant? Surely sanitizing arguments to prevent segfaults is worth a few nano-seconds? Matti

[Python-Dev] Replace debug runtime checks in release mode with assertions in debug mode

Hi, I would like to replace runtime checks on C function arguments with assertions. For example, replace: PyObject * PyDict_GetItemWithError(PyObject *op, PyObject *key) { if (!PyDict_Check(op)) { PyErr_BadInternalCall(); return NULL; } ... } with: PyObject *

[Python-Dev] Re: PEP 674 – Disallow using macros as l-value (version 2)

On Mon, Jan 31, 2022 at 3:57 PM Petr Viktorin wrote: > Remove the point from the Abstract? > (...) > I think you should make it clear that the percentage was taken after > fixing many of the projects. Thanks for your review. I pushed a change to take your remarks in account:

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 07. 02. 22 15:29, Victor Stinner wrote: On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote: CPython is also affected by these issues, but the benefits of PEP 674 (alone) are too indirect, so I chose to avoid mentioning CPython issues directly, to avoid confusion. A concrete example of

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote: > CPython is also affected by these issues, but the benefits of PEP 674 > (alone) are too indirect, so I chose to avoid mentioning CPython > issues directly, to avoid confusion. A concrete example of problem caused by exposing structures in

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 07. 02. 22 14:26, Victor Stinner wrote: On Mon, Feb 7, 2022 at 2:08 PM Petr Viktorin wrote: Basically, instead of "We'll remove this API now because it prevents moving to a hypothetical moving garbage collector", it should be "Here is a moving garbage collector that speeds Python up by 30%,

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On Mon, Feb 7, 2022 at 2:08 PM Petr Viktorin wrote: > Basically, instead of "We'll remove this API now because it prevents > moving to a hypothetical moving garbage collector", it should be "Here > is a moving garbage collector that speeds Python up by 30%, but to add > it we need to remove these

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 31. 01. 22 16:14, Victor Stinner wrote: On Mon, Jan 31, 2022 at 4:03 PM Petr Viktorin wrote: If we change the stable ABI, I would prefer to fix multiple issues at once. Examples: * No longer return borrowed references (ex: PyDict_GetItem is part of the stable ABI) and no longer steal

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

On 2/6/2022 4:44 PM, Christian Heimes wrote: If I had the power and time, then I would replace urllib with a simpler, reduced HTTP client that uses platform's HTTP library under the hood (WinHTTP on Windows, NSURLSession (?) on macOS, Web API for Emscripten, maybe curl on Linux/BSD). For

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

On 2/5/2022 4:09 PM, Guido van Rossum wrote: On Sat, Feb 5, 2022 at 5:18 AM Steve Dower > wrote: The gap this has with what I'd like to see is that it will only work for compile-time strings. If instead it could work for an arbitrary uint8_t

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

> Christian proposes that having a simpler scope rewrite of it might be nice, > but I think disruption to the world and loss of trust in Python would be > similar either way. Please don't remove urllib.  There are mountains of code that rely on it.  A much better idea, IMO, would be to add a