On Tue, Feb 8, 2022 at 9:49 AM Serhiy Storchaka wrote:
>
> 07.02.22 17:55, Victor Stinner пише:
> > I'm asking to replace runtime checks with assertions when the C API is
> > "obviously" misused: replace PyErr_BadInternalCall(),
> > _Py_CheckFunctionResult() and _Py_CheckSlotResult() with
Thank you for submitting PEP 670 (Convert macros to functions in the
Python C API)!
The steering council is still discussing it. We're not ready to accept
the PEP as a whole, but there are parts on which we agree unanimously.
To unblock the work, we're making the following pronouncements:
*All
Am 03.02.22 um 22:41 schrieb Gregory P. Smith:
datapoint: an internal code search turns up blender, multidict, and
typed_ast as open source users of _Py_IDENTIFIER . Easy to clean up
as PRs. There are a couple of internal uses as well, all of which are
similarly easy to address and are only
07.02.22 19:09, Victor Stinner пише:
> After my NAN change (bpo-46640), Petr Viktorin asked me to update the
> PEP 7. I proposed a change to simply say that "Python 3.11 and newer
> versions use C99":
But public headers should be compatible with C++, and not all C99
features are compatible with
... and there are also plenty examples out there of using http.server as
a quick HTTP server for trying out new things, testing and teaching.
FWIW: I find this discussion a bit strange. Python's stdlib is
supposed to provide basic tooling for a breadth of use cases,
with emphasis on "basic" and
On 07. 02. 22 18:09, 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:
What does pyperformance say about --enable-optimizations builds with all of
those compiled out vs today?
I like the runtime safety checking for purposes of making the lives of
Python C API users easier. But without the use of assertion enabled CPython
builds being the norm during development (we
07.02.22 17:55, Victor Stinner пише:
> I'm asking to replace runtime checks with assertions when the C API is
> "obviously" misused: replace PyErr_BadInternalCall(),
> _Py_CheckFunctionResult() and _Py_CheckSlotResult() with assertions.
> The exact scope should be defined.
Would not be better to
On Tue, Feb 8, 2022 at 2:02 PM Steve Dower wrote:
> All the C99 library is supposedly supported, but there are (big?) gaps
> in the compiler support.
Some Visual Studio 2019 updates on the Microsoft blog.
March 2020: C99 _Pragma
On 2/8/2022 1:35 AM, Gregory P. Smith wrote:
While we're at it are 64 bit floats required for either cPython or
Python the language?
CPython: yes. we use a double.
Python the language: no. (float is single precision on many micropython
platforms as it saves precious ram and
Petr, SC, thanks for your time and response! Just a quick comment:
> On 8 Feb 2022, at 11:32, Petr Viktorin wrote:
>
> In effect, the SC accepts the first part of the PEP, except cases where:
What status does that put the PEP in?
E
___
Python-Dev
On 2/8/2022 9:52 AM, Petr Viktorin wrote:
On 07. 02. 22 18:09, Victor Stinner wrote:
In 2022, C99 is now well supported by C compilers supported by Python:
GCC, clang, MSVC.
Does MSVC support all of C99? I haven't found any documentation claiming
that... but I'm also not familiar with MSVC.
According to the docs[^1], MSVC does _not_ support all of C99. OTOH they claim
conformance with both C11 and C17, using the /std:c11 and /std:c17 compiler
flags.
[^1]:
https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170
> On 8 Feb 2022, at
Inada Naoki schrieb am 08.02.22 um 06:15:
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
Hi Petr,
Thanks for the SC review, it's very helpful! I know that it's a big PEP :-)
On Tue, Feb 8, 2022 at 11:33 AM Petr Viktorin wrote:
> *All other things being equal, static inline functions are better than
> macros.*
> Specifically, inline static functions should be preferred over
>
On Wed, 9 Feb 2022 at 04:50, Christopher Barker wrote:
> So my thoughts:
>
> Rather than deprecate urllib, we refactor it a bit (and maybe deprecate parts
> of it), so that it:
>
> 1) contains the core building blocks: e.g. urllib.parse with which to build
> "better" libraries,
>
> 2) make the
On Tue, Feb 8, 2022 at 1:31 AM Marc-Andre Lemburg wrote:
> FWIW: I find this discussion a bit strange. Python's stdlib is
> supposed to provide basic tooling for a breadth of use cases,
> with emphasis on "basic" and "breadth".
>
> urllib is such a basic library and covers one of the main
> use
On Wed, Dec 15, 2021 at 10:15 AM Eric Snow wrote:
> Yes, I plan on benchmarking the change as soon as we can run
> pyperformance on main.
I just ran the benchmarks and the PR makes CPython 4% slower. See
https://github.com/python/cpython/pull/19474#issuecomment-1032944709.
-eric
On Mon, Feb 7, 2022 at 5:51 PM Jim J. Jewett wrote:
> 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
On Mon, Feb 7, 2022 at 4:59 PM S Pradeep Kumar wrote:
> 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
On Tue, Feb 8, 2022 at 8:30 AM Victor Stinner wrote:
> Hi Petr,
>
> Thanks for the SC review, it's very helpful! I know that it's a big PEP :-)
>
> On Tue, Feb 8, 2022 at 11:33 AM Petr Viktorin wrote:
> > *All other things being equal, static inline functions are better than
> > macros.*
> >
Brett Cannon writes:
>> Ah. I don't know if CIs like GitHub Actions and Azure Pipelines
>> provide Python debug builds. If if it's not the case, it would be nice
>> to have the choice :-)
>>
>
> They do not:
>
On Tue, Feb 08, 2022 at 05:48:46PM -0800, Gregory P. Smith wrote:
> On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano wrote:
> > If the answer to those questions are Yes, that rules out using Unums,
> > posits, sigmoid numbers etc as the builtin float. (The terminology is a
> > bit vague, sorry.)
On Tue, Feb 8, 2022 at 2:25 PM Steven D'Aprano wrote:
> On Mon, Feb 07, 2022 at 05:35:17PM -0800, Gregory P. Smith wrote:
>
> > CPython: yes. we use a double.
> > Python the language: no. (float is single precision on many micropython
> > platforms as it saves precious ram and performance,
On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano wrote:
> On Mon, Feb 07, 2022 at 06:23:52PM +, Mark Dickinson wrote:
>
> > - Should we require IEEE 754 floating-point for
> CPython-the-implementation?
> > - Should we require IEEE 754 floating-point for Python-the-language?
>
> If the answer
> Maybe a more practical approach would be to use C99 "except of
features not supported by MSVC of Visual Studio 2019"?
This could be formulated in a more neutral way by saying
"C99 without the things that became optional in C11", or perhaps
"C11 without optional features" (at least from the POV
On Mon, Feb 07, 2022 at 05:35:17PM -0800, Gregory P. Smith wrote:
> CPython: yes. we use a double.
> Python the language: no. (float is single precision on many micropython
> platforms as it saves precious ram and performance, plus microcontroller
> fpu hardware like an M4 is usually single
On Mon, Feb 07, 2022 at 06:23:52PM +, Mark Dickinson wrote:
> - Should we require IEEE 754 floating-point for CPython-the-implementation?
> - Should we require IEEE 754 floating-point for Python-the-language?
If the answer to those questions are Yes, that rules out using Unums,
posits,
On Tue, Feb 08, 2022 at 12:44:46PM +, Steve Dower wrote:
> Agreed. CPython should be specific, Python should be as vague as
> possible. Otherwise, we would prevent _by specification_ using Python as
> a scripting language for things where floats may not even be relevant.
I don't think that
On Tue, 8 Feb 2022 00:39:12 -0800
"Gregory P. Smith" wrote:
> What does pyperformance say about --enable-optimizations builds with all of
> those compiled out vs today?
>
> I like the runtime safety checking for purposes of making the lives of
> Python C API users easier. But without the use of
On Tue, 08 Feb 2022 01:12:22 -
"Jim J. Jewett" 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?
> - Should we require IEEE 754 floating-point for Python-the-language?
>
> I don't
On Mon, 7 Feb 2022 15:29:39 +0100
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.
> Why do you think the stdlib *must *provide an example implementation
> for this specific scenario? Is there something unique to HTTP request
> handling that you feel is important to demonstrate?
*must* is too strong, but I would use a very strong *should*.
I think the stdlib should provide
33 matches
Mail list logo
