[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode
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 should try to shift that norm in the community and make it the popular CI system default regardless), I'm concerned this would hurt the developers who need it most. Having some idea of what it actually gains us performance wise would be useful. -gps On Mon, Feb 7, 2022 at 3:30 PM Brett Cannon wrote: > > > 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 build, unless >> ./configure --with-assertions is used. >> >> >> > And you're sure that each and every single call to any of those is >> better off being an assert()? >> >> For many years, many C extensions raised an exception *and* returned a >> result: that's a bug. The strange part is that in some cases, the >> exceptions is somehow ignored and the program continues running fine. >> >> That's why I added _Py_CheckFunctionResult() and _Py_CheckSlotResult() >> which helped to catch such bugs. But before that, these programs were >> running fine :-) >> >> So it's not fully clear to me there was really a bug or it's just that >> Python became more pedantic :-) >> >> >> About PyErr_BadInternalCall(): in 10 years, I saw a few SystemError >> raised by this function, but usually when I hacked on Python. It's >> really rare to hit such bug. >> >> >> > (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.) >> >> If you don't develop C extensions, the release mode is faster and enough >> ;-) >> >> 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: > https://github.com/actions/python-versions/blob/797eb71c41e47d194f563c7ef01790d734534788/builders/ubuntu-python-builder.psm1#L35-L38 > . > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/VRISRYZVU47PQRWKHN77CV5545SKUI5O/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XNB4ZUTFJFRCDCG2HJ36INGH3PMLFMP6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode
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 call Py_FatalError() in PyErr_BadInternalCall() etc? It can even be controlled by some option or envvar, even in release mode (just with different defaults in debug and release modes). ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q6JOWJND63URG3Y2WAAM7QJCCKNFUQAE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
... 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 "breadth". urllib is such a basic library and covers one of the main use cases for Python we have. It would be pretty much beside the point of the stdlib to remove such basic functionality and make Python less attractive and less useful for beginners. Anything more complex can be dealt with on PyPI, as it is already happening. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 08 2022) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AKWL7QKOZJDODM3LIX4BBYZ4HMXZC3CZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
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 C++. It is not a matter of style, it is a matter of compatibility. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZDGZN46UQAPJY5EF5A3GYA5DT4XX6AQO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
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: https://www.python.org/dev/peps/pep-0007/ I modified Python 3.11 to require more C99 features of the header: * bpo-45440: copysign(), hypot(), isfinite(), isinf(), isnan(), round() * bpo-46640: NAN 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": https://github.com/python/peps/pull/2309 I would prefer to not have to give an exhaustive list of C99 features used by CPython, since it's unclear to me what belongs to C99 or to ISO C89. As I wrote before, Python already uses C99 features since Python 3.6. On my PEP PR, Guido van Rossum asked me to escalate the discussion to python-dev, so here I am :-) In "C99", the number "99" refers to the year 1999, the standard is now 23 years old: https://en.wikipedia.org/wiki/C99 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. Do we need to support a subset like "C99 except the features that were removed in C11"? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XUNLZB5Q5BCWLX7C77WBD34ZU33RPVNM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode
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 assertions. > > The exact scope should be defined. > > Would not be better to call Py_FatalError() in PyErr_BadInternalCall() > etc? It can even be controlled by some option or envvar, even in release > mode (just with different defaults in debug and release modes). It's unrelated to what I said, but yeah it sounds like a good idea :-) I already did it manually (local patch) sometimes to help me debugging C extensions bugs, or when I ran a fuzzer on Python. Otherwise, the SystemError exception raised by PyErr_BadInternalCall() can be "hidden silently": a function can catch it and ignores it. _Py_CheckFunctionResult() already uses Py_FatalError() if Python is build with Py_DEBUG macro defined (debug build). Maybe we can do something similar than iobase_finalize(): change the behavior (log an exception) if Py_DEBUG or if dev_mode config is non-zero (python3 -X dev / PYTHONDEVMODE=1). Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M4FAFQRV23Z6LFTUJKTSSSPKGQRTRTX6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API
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 other things being equal, static inline functions are better than
macros.*
Specifically, inline static functions should be preferred over
function-like macros in new code. Please add a note about this to PEP 7.
*The performance impact of changing macros to static inline functions is
negligible.*
The performance changes are indistinguishable from noise caused by other
factors, such as layout changes and specific compiler optimizations.
It's possible that this isn't true in all cases. If any are found, they
should be kept as macros and added to the benchmark suite to avoid
regressions.
More generally, if there is a non-obvious reason for a conscious design
decision, it should be explained (e.g. in a comment) to help future
developers.
*When there is no backwards compatibility issue, macros can be changed
to static inline functions.*
In effect, the SC accepts the first part of the PEP, except cases where:
a macro is converted to macro and function ("Cast to PyObject*"), and
where the return value is removed.
Please do the changes in several smaller pull requests, don't skip
reviews, and be prepared to revert if any issues are found.
The straightforward macros should be converted first. When they are, we
hope that it will become easier to evaluate the remaining ones.
- Petr, on behalf of the Steering Council
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/IJ3IBVY3JDPROKX55YNDT6XZTVTTPGOP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Moving away from _Py_IDENTIFIER().
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 in code that is expected to need API cleanup tweaks between CPython versions. typed_ast is mostly legacy, to be used for parsing Python code < Python 3.8. It's end of life is scheduled when Python 3.7 end of lifes in June 2023. I believe we can easily get away with just copying the _Py_IDENTIFIER macros over to its source code in typed_ast. - Sebastian ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NYRNJRDSRPSABNSSQCU7NGJLUTZPENGM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
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 performance, plus microcontroller fpu hardware like an M4 is usually single precision 32bit) 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. It's not even about hardware capabilities (unless you believe Python is only for running in a terminal, in which case we'll just have to disagree). It could be about an app using short Python snippets as a customisation language for some domain-specific task rather than inventing a brand new language for it. The more "it's-only-Python-if-it-has-X" restrictions we have, the less appealing we become. Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/W4GVXJZJ6EKNIEQVFIKRGU7PNN3OTNUP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API
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 mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Z44YV6IXXAQ4W3HDL5UN2BR5FHYQLQ3S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
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. Do we need to support a subset like "C99 except the features that were removed in C11"? I couldn't find any information either (from public sources, at least, haven't asked the team directly yet). All the C99 library is supposedly supported, but there are (big?) gaps in the compiler support. Possibly these are features that were removed in C11? I don't know what is on that list. It seems C11 and C17 are supported [1], though I know for sure we have contributors who aren't using a recent enough compiler version to have it :) Personally, I see no reason to "require" C99 as a whole. We have a style guide already, and can list the additional compiler features that we allow along with guidance on updating existing code and ensuring compatibility. I don't see much risk requiring the C99 standard library, though. It's the compiler features that seem to have less coverage. Cheers, Steve [1]: https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UZACKMZGN2PUGNQ74FQX2V4UTQAA6DWB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
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 10:52, Petr Viktorin wrote: > > Does MSVC support all of C99? I haven't found any documentation claiming > that... but I'm also not familiar with MSVC. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AYZC3F73THZXNMSYWSFPXFKAUQ5NBTDO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
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 https://devblogs.microsoft.com/cppblog/announcing-full-support-for-a-c-c-conformant-preprocessor-in-msvc/ > The _Pragma operator has been one of the long-standing deficiencies of the > preprocessor, and a blocker in being standard conformant in C++ and C99. September 2020: C11 and C17 https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ Maybe a more practical approach would be to use C99 "except of features not supported by MSVC of Visual Studio 2019"? In practice, we can try to support VS 2017, the version currently recommended by the devguide: https://devguide.python.org/setup/#windows-compiling We already have fallbacks for compilers which don't support C99. We don't have to remove these fallbacks if they are still needed by popular C compilers. For example, I'm fine with keeping basic compatbility support with ICC if it remains reasonable, even if we don't "officially" support ICC (ex: no buildbot). Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/L5TIKLYYAHGCSUUWFHXW4ZBHH2TDIHUB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Moving away from _Py_IDENTIFIER().
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 compatible than just leaving _Py_IDENTIFIER alone and just not using it, I'd say let's not spend more time on that alternative and just focus on the two other horses still in the race: immortal objects or what you have now. I think it's because statically allocated strings are not interned. That would explain such a difference. I think deepfreeze should stop using statically allocated strings for interned strings too. … or consider the statically allocated strings the interned string value. Unless another one already exists, but that shouldn't be the case for CPython internal strings. Stefan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5NE7EI3TVW4C3ZZI6LO5HNPIZRQNPMHG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API
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
> function-like macros in new code. Please add a note about this to PEP 7.
Ok, I created: https://github.com/python/peps/pull/2315
> *When there is no backwards compatibility issue, macros can be changed
> to static inline functions.*
> In effect, the SC accepts the first part of the PEP, except cases where:
> a macro is converted to macro and function ("Cast to PyObject*"),
Right now, a large number of macros cast their argument to a type. A
few examples:
#define PyObject_TypeCheck(ob, type)
PyObject_TypeCheck(_PyObject_CAST(ob), type)
#define PyTuple_GET_ITEM(op, i) (_PyTuple_CAST(op)->ob_item[i])
#define PyDict_GET_SIZE(mp) (assert(PyDict_Check(mp)),((PyDictObject
*)mp)->ma_used)
#define PyWeakref_GET_OBJECT(ref) (... ((PyWeakReference
*)(ref))->wr_object ...)
Does it mean that these macros must remain macros?
PEP 670 proposes adding a macro to still cast their arguments to the
requested type so the PEP doesn't add any new compiler warnings. The
PEP proposes to consider removing these implicit casts later (to
reduce the scope and limit annoyance caused by the PEP).
If the macro is converted to a static inline function without such
convenient macro, C extensions which don't pass the expected types
will get spammed by warnings. Well, it's easy to fix, and once it is
fixed, the code remains compatible with old Python versions.
I'm not sure that I understood the SC statement here: does it mean
that these specific macros (which cast their arguments) must remain
macros, or that it's ok to convert them to static inline functions
(even if it can emit new warnings)?
If the SC is ok to add new compiler warnings, I'm fine with it. Most
functions are documented with an exact type, they are not documented
to cast implicitly their arguments to the expected types.
For example, Py_INCREF() expects a PyObject* type in the documentation:
https://docs.python.org/dev/c-api/refcounting.html#c.Py_INCREF
--
Or is the problem that having a macro to wrap a static inline function
requires to change the function name? Well, technically, it's not
needed... I wrote a PR so the macro and the function have the same
name:
https://github.com/python/cpython/pull/31217
For example, the Py_INCREF() macro now calls Py_INCREF(), instead of
calling _Py_INCREF().
Static inline functions are not part of the ABI since they are
inlined, but it's maybe better to avoid the "_" prefix to avoid
confusion in debuggers and profilers (especially when comparing old
and new Python versions).
> and where the return value is removed.
In this case, I propose to leave these macros unchanged in PEP 670 in
this case, as it already excludes macros which can be used as l-values
(macros changed by PEP 674).
I would prefer to have the whole PEP 670 either accepted or rejected.
I'm not comfortable with a half-accepted status, it's misleading for
readers.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/NHMVI5HSKDQJZG5F457MKFRXRN7GSY2G/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
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 cases for Python we have. Exactly. However, it is also a bit of an "attractive nuisance". For example, there is a lot of code in some of my major projects that use urllib for more complex cases, where we'd be much better off with requests, or ... Yes, that's mainly the result of our team's atrocious lack of code review, but this code was written by smart productive people. The fact is that the stdlib is the first place folks look for stuff, and if what you are looking for is there, then many people won't think: "maybe there's a better, and well supported, package on PyPi for this" 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 "easy stuff easy" -- e.g. a basic http: request. - For instance, I'd like to see an API that's kind of "requests-lite" And much better docs explain when you should use it, and when you might want to look for another library (even if it's the stdlib http.client) I note that I don't see any discussion of that in urllib dics, whereas http.client does have the suggestion front and center that you might want to use requests. Yes, the web moves fast, but it's also pretty backward compatible - folks keep old browsers around for an astonishingly long time! So I'd think cPython release Cycle shold be able to keep up with all but the very latest. > make Python less attractive and less useful for beginners. On this point, I'm not so sure -- the first thing I do for beginners is to point them to requests, as it's easier to use :-) -- but see my point above, that's why it would be good to put an easy-to-use-for-the-basics API in the stdlib -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FLU522SFBBSMMXHRDBXYYGXD3IQ2CD6K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
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 "easy stuff easy" -- e.g. a basic http: request. > - For instance, I'd like to see an API that's kind of "requests-lite" > > And much better docs explain when you should use it, and when you might want > to look for another library (even if it's the stdlib http.client) This sounds like a decent plan. I'd like to add my voice to the appeal to keep urllib.parse; in fact, of all the places where I've used anything from urllib, only two of them are anything other than urllib.parse. (One is an old script that I specifically wanted to be as shareable as possible, so I restricted it to the stdlib; the other catches urllib.error.URLError thrown by a third-party library.) If there are security issues with urllib.request, I wouldn't shed many tears about its deprecation. A "requests-lite" module would certainly be handy, but it's hard to judge how much wants to be in the stdlib and how much can be pushed off to a pip-installable module: > the first thing I do for beginners is to point them to requests, as it's > easier to use :-) Exactly my thoughts :) But a very very simple HTTP/HTTPS GET request endpoint would be a great bootstrapping aid. Consider: with nothing but the stdlib, you could fetch a file from some server, unzip it (zipfile module), and import it. For building dirt-simple install scripts, this kind of thing is really REALLY handy, and I'd rather not have to use plain TCP sockets to do it :) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VVGKL2TA3UXDD3RDASIYSGEOLMTKPOSH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL
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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3TT6Q5TQLUMLL5TWTKHRTXQ3XATHIUBW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC on PEP 675: Arbitrary Literal Strings
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 sorry about this oversight. I've fixed it in > https://github.com/python/peps/pull/2313 > No need to apologize! Writing your first PEP is a lot to take on and something like this is easy to overlook. Besides, I blame Jelle as sponsor. 😉 > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PHIQCHLNRRVSHSPEPAGWVITBXV3JCXTK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API
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.*
> > Specifically, inline static functions should be preferred over
> > function-like macros in new code. Please add a note about this to PEP 7.
>
> Ok, I created: https://github.com/python/peps/pull/2315
>
>
> > *When there is no backwards compatibility issue, macros can be changed
> > to static inline functions.*
> > In effect, the SC accepts the first part of the PEP, except cases where:
> > a macro is converted to macro and function ("Cast to PyObject*"),
>
> Right now, a large number of macros cast their argument to a type. A
> few examples:
>
> #define PyObject_TypeCheck(ob, type)
> PyObject_TypeCheck(_PyObject_CAST(ob), type)
> #define PyTuple_GET_ITEM(op, i) (_PyTuple_CAST(op)->ob_item[i])
> #define PyDict_GET_SIZE(mp) (assert(PyDict_Check(mp)),((PyDictObject
> *)mp)->ma_used)
> #define PyWeakref_GET_OBJECT(ref) (... ((PyWeakReference
> *)(ref))->wr_object ...)
>
> Does it mean that these macros must remain macros?
>
> PEP 670 proposes adding a macro to still cast their arguments to the
> requested type so the PEP doesn't add any new compiler warnings. The
> PEP proposes to consider removing these implicit casts later (to
> reduce the scope and limit annoyance caused by the PEP).
>
> If the macro is converted to a static inline function without such
> convenient macro, C extensions which don't pass the expected types
> will get spammed by warnings. Well, it's easy to fix, and once it is
> fixed, the code remains compatible with old Python versions.
>
> I'm not sure that I understood the SC statement here: does it mean
> that these specific macros (which cast their arguments) must remain
> macros, or that it's ok to convert them to static inline functions
> (even if it can emit new warnings)?
>
> If the SC is ok to add new compiler warnings, I'm fine with it. Most
> functions are documented with an exact type, they are not documented
> to cast implicitly their arguments to the expected types.
>
> For example, Py_INCREF() expects a PyObject* type in the documentation:
> https://docs.python.org/dev/c-api/refcounting.html#c.Py_INCREF
>
> --
>
> Or is the problem that having a macro to wrap a static inline function
> requires to change the function name? Well, technically, it's not
> needed... I wrote a PR so the macro and the function have the same
> name:
> https://github.com/python/cpython/pull/31217
>
> For example, the Py_INCREF() macro now calls Py_INCREF(), instead of
> calling _Py_INCREF().
>
> Static inline functions are not part of the ABI since they are
> inlined, but it's maybe better to avoid the "_" prefix to avoid
> confusion in debuggers and profilers (especially when comparing old
> and new Python versions).
>
>
> > and where the return value is removed.
>
> In this case, I propose to leave these macros unchanged in PEP 670 in
> this case, as it already excludes macros which can be used as l-values
> (macros changed by PEP 674).
>
> I would prefer to have the whole PEP 670 either accepted or rejected.
> I'm not comfortable with a half-accepted status, it's misleading for
> readers.
>
That's why we pointed out what is not controversial and can be done without
a PEP. That lets you update the PEP for everything remaining so we can
focus on what really need discussion instead on things that are an obvious
"yes" to us.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/TCZDU6QBSHYBZQCVAJZBJMDZQTTI7BIL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
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 > exception of 3rd party Requests, the docs don't even mention them. > And as soon as httpx hits 1.0 I plan to update the docs to point at it. But until that occurs I personally do not want to have a debate about whether httpx's 0.N version number means it shouldn't be recommended. > > Saying "You can do better, but we won't tell you how" is pretty rude to > beginners, and we should not do it. > > Delegating to the operating system may be sensible for a production > system, and there is nothing wrong with saying so in the docs, and it would > be great if we made that easy. But it is absolutely not a reasonable > replacement for a straightforward (possibly inefficient and non-scalable) > implementation written in python that people can read and use for > reference. urllib shouldn't be deprecated until we have a better solution > to *that* use case that is also in the stdlib. (That might well be worth > doing, but it should happen before the deprecation.) > 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? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XNYPBSXW7DIBQN5YLXCWUOBLIEBRMPEP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
> 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 simple source-included examples of most things. I think the case is even stronger when it is: (1) a fairly simple protocol (such as version 1 of http was) -- QUIC wouldn't count for a simple demonstration. (2) something new users are likely to find motivating. Short of "here is a way to do IO", and maybe "write a simple game", "get something from the web" is probably the most obvious case. (3) something where bootstrapping might be an issue (network protocols, particularly web downloads). Network access is not an always-available resource. Even when it is available, there is sometimes a barrier between "available in python" and "I could read it on my phone, but can't get it open in python". (4) something where a a beginner is likely to be overwhelmed by choices if we just say "use a 3rd party module". (5) something with a backwards-compatibility story in the stdlib already. As a side note, are there concerns about urllib.robotparser being broken or obsolete, or was that part of the deprecation proposal just contagion from urllib.request? -jJ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HF5V6SFWV4BZUAOJTSEBD6DSZWSJONAM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
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 being *vague* is desirable. Being *permissive* on the other hand may be. > It's not even about hardware capabilities (unless you believe Python is > only for running in a terminal, in which case we'll just have to > disagree). It could be about an app using short Python snippets as a > customisation language for some domain-specific task rather than > inventing a brand new language for it. I'm sorry, I don't understand what point you are trying to make here. Regarding "running in a terminal", I don't see how the environment (terminal, GUI, something else) is relevent. Regarding your second point, about domain-specific tasks, I don't understand. If your domain-specific task doesn't need to use floats, just don't use floats. There's surely no need to invent a whole new language for some task because your app only needs to do string processing, say. Have I misunderstood what you are trying to say? -- Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CFLJJN64M4WW6DTRLSGZZTQLU7OHW5OH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
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 precision 32bit) If we are to *officially* support non-double floats, it would be nice if sys.float_info were to tell us explicitly how wide the floats are rather than having to try to reverse engineer it from the other information there. A floating point expert can probably look at this: sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, radix=2, rounds=1) and immediately recognise that those values imply a 64-bit float, but I expect most people will not. If Python the language is going to support single, double, quad precision floats, and maybe even minifloats with just 16 or even fewer bits, then can we please add a field to float_info telling us how many bits the floats have? -- Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EUWN4TDI62FK7L6SOG6IAV3AOINDBH6O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
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, sigmoid numbers etc as the builtin float. (The terminology is a bit vague, sorry.) Do we want that? https://ieeexplore.ieee.org/document/808 https://en.wikipedia.org/wiki/Unum_%28number_format%29 https://github.com/interplanetary-robot/SigmoidNumbers Posits are hyped as "better than IEEE-754", I have no idea if it is all hype or if they actually are better or just different. -- Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7LUAQ32ZAHKWBJHLHUYEB7I5BZNDXGB7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone
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.
>
> A concrete example of problem caused by exposing structures in the C
> API (unrelated to PEP 674). It's a tricky problem...
>
> typedef struct {
> PyObject_VAR_HEAD
> Py_hash_t ob_shash;
> char ob_sval[1];
> } PyBytesObject;
>
> The "char ob_sval[1];" syntax used to declare an array is an undefined
> behavior if the array is longer in memory. On a bytes object of 4
> bytes, accessing ob_sval[3] works, but is an undefined behavior.
>
> => see https://bugs.python.org/issue40120 for details
>
> The problem can be solved by using "char ob_sval[];" syntax, but we
> cannot use this syntax in the public C header, since it causes
> compiler errors if the header is built with a C++ compiler (not to
> build Python itself, but build a C++ extension using the Python C
> API). Removing the structure from the public C API would solve the C++
> issue.
You could also have something like:
typedef struct {
PyObject_VAR_HEAD
Py_hash_t ob_shash;
#ifdef __cpluscplus
char ob_sval[1];
#else
char ob_sval[];
#endif
} PyBytesObject;
Regards
Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/HWXZIISALVHAHT4HSBG33S7IFKLIYBNG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode
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 assertion enabled CPython > builds being the norm during development (we should try to shift that norm > in the community and make it the popular CI system default regardless), I'm > concerned this would hurt the developers who need it most. > > Having some idea of what it actually gains us performance wise would be > useful. Exactly my sentiment. I'm also skeptical about the performance argument in this case, but willing to be shown wrong :-) Regards Antoine. > > -gps > > On Mon, Feb 7, 2022 at 3:30 PM Brett Cannon wrote: > > > > > > > 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 build, unless > >> ./configure --with-assertions is used. > >> > >> > >> > And you're sure that each and every single call to any of those is > >> better off being an assert()? > >> > >> For many years, many C extensions raised an exception *and* returned a > >> result: that's a bug. The strange part is that in some cases, the > >> exceptions is somehow ignored and the program continues running fine. > >> > >> That's why I added _Py_CheckFunctionResult() and _Py_CheckSlotResult() > >> which helped to catch such bugs. But before that, these programs were > >> running fine :-) > >> > >> So it's not fully clear to me there was really a bug or it's just that > >> Python became more pedantic :-) > >> > >> > >> About PyErr_BadInternalCall(): in 10 years, I saw a few SystemError > >> raised by this function, but usually when I hacked on Python. It's > >> really rare to hit such bug. > >> > >> > >> > (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.) > >> > >> If you don't develop C extensions, the release mode is faster and enough > >> ;-) > >> > >> 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: > > https://github.com/actions/python-versions/blob/797eb71c41e47d194f563c7ef01790d734534788/builders/ubuntu-python-builder.psm1#L35-L38 > > . > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-dev@python.org/message/VRISRYZVU47PQRWKHN77CV5545SKUI5O/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/X53ORDVNOTYRLFQ6QNR3NCXCL4AO7ISC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
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 have strong opinions on the first two, but for the language > definition, I think the most we should say is "if an implementation does not > support IEEE 754 floating-point, this must be mentioned in the documentation > as an implementation limit." This is more about platform support than about implementation support. An implementation using a C "float" or "double" (or whatever the equivalent in another implementation language) will de facto support IEEE 754 on platforms that support it. Sure, a Python implementation may also choose to rewrite its own floating-point type from scratch, but that sounds unlikely. Regards Antoine. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JO6BB3JZBPELKVT5HGNFK2RTQBZ3C2Y7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
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, plus microcontroller > > fpu hardware like an M4 is usually single precision 32bit) > > If we are to *officially* support non-double floats, it would be nice if > sys.float_info were to tell us explicitly how wide the floats are rather > than having to try to reverse engineer it from the other information > there. > > A floating point expert can probably look at this: > > sys.float_info(max=1.7976931348623157e+308, max_exp=1024, > max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, > min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, > radix=2, rounds=1) > > and immediately recognise that those values imply a 64-bit float, but I > expect most people will not. If Python the language is going to support > single, double, quad precision floats, and maybe even minifloats with > just 16 or even fewer bits, then can we please add a field to float_info > telling us how many bits the floats have? > There is no need to know how many bits it is. The meaningful information about precision and accuracy from a math point of view is already expressed in float_info. the size in bits isn't relevant. You can derive the size from that if you'd like and are willing to assume a binary format. binary_bits = ~mant_dig+log2(max_exp)... But that tells you less than sys.float_info. -gps ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CRWZFO5RV2FLXIBH6GV6QGSDXWUZOZCR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
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 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.) Do we want that? > It does not rule anything else out should they become viable. This is just a statement that to build cpython we require ieee754 support. It does not say anything about how our Python float type is implemented internally. Should a meaningful large-os platform come along that promotes the use of a different format available from C we could make use of that and loosen the policy as needed. What updating our requirement for CPython would mean is that the likely unexercised outside our own __set_format__ using test suite "unknown_format" code in https://github.com/python/cpython/blob/main/Objects/floatobject.c could go away until such time as a platform with an actual different format springs into existence. Driveby floatobject.c code inspection: It is odd that we do ieee_be/ieee_le/unknown conditionals as a runtime check rather than configure time check as that means we compile the code for three implementations into our float implementation on all platforms despite them each using only one - I guess that was done for testing purposes presumably in the 1.x era when viable platforms were weirder as standards traction grew - today I'd call that dead code bloat. -gps > > https://ieeexplore.ieee.org/document/808 > > https://en.wikipedia.org/wiki/Unum_%28number_format%29 > > https://github.com/interplanetary-robot/SigmoidNumbers > > Posits are hyped as "better than IEEE-754", I have no idea if it is all > hype or if they actually are better or just different. > > > -- > Steve > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/7LUAQ32ZAHKWBJHLHUYEB7I5BZNDXGB7/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/N3Z5PFOALORZ4Z7KGNSHJ7QL47D4SYRJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11
> 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 of MSVC, haven't checked the other compilers/platforms for C11-compliance). > In practice, we can try to support VS 2017, the version currently recommended by the devguide: That is becoming dated quickly, as Microsoft has deprecated, and is removing, that version quite rapidly from their CI services (azure/GHA), i.e. mid March, see: https://github.com/actions/virtual-environments/issues/4312. It's understandable in the sense that they don't want to support a third version in addition to vs2022 and vs2019, but the net effect is that very few (open source) projects will keep using vs2017 going forward. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IIZ6LXK2MANUHZAMYSXDF5KPF3VIRKDJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
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.) Do we want that? > > It does not rule anything else out should they become viable. This is just > a statement that to build cpython we require ieee754 support. It does not > say anything about how our Python float type is implemented internally. Posits do not implement IEEE-754. They aren't merely a different internal representation of the IEEE-754 floating point standard, they implement a different numeric system altogether. Things that IEEE-754 require, such as signed zero and signed infinity, are not supported by posits. Posits include a single unsigned zero and a single unsigned infinity. Earlier, I made a mistake: I misremembered that posits support a single NAN, and so I removed Mark's question about requiring NANs from my quoting. I was wrong to do so: posits do not have any NANs. So if we require NANs, or IEEE-754, that rules out posits as the builtin float. -- Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IKJSL3CEL7YZX3XPCJM4SA6BXVFN27Q3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode
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: > https://github.com/actions/python-versions/blob/797eb71c41e47d194f563c7ef01790d734534788/builders/ubuntu-python-builder.psm1#L35-L38 > . You can get a debug variant using from https://github.com/deadsnakes/action. bye, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HCPLJIUJFRCMJWVTXKNJEHTWMGO7AQNQ/ Code of Conduct: http://python.org/psf/codeofconduct/
