Mailman 3 August 2024 - Python-announce-list

NumPy 2.0.2 released
by Charles R Harris 26 Aug '24

26 Aug '24

Hi All On behalf of the NumPy team, I'm pleased to announce the release of NumPy 2.0.2. NumPy 2.0.2 is a maintenance release that fixes bugs and regressions discovered after the 2.0.1 release. This release supports Python 3.9-3.12. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.0.2>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v2.0.2>. *Contributors* A total of 13 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Bruno Oliveira + - Charles Harris - Chris Sidebottom - Christian Heimes + - Christopher Sidebottom - Mateusz Sokół - Matti Picus - Nathan Goldbaum - Pieter Eendebak - Raghuveer Devulapalli - Ralf Gommers - Sebastian Berg - Yair Chuchem + *Pull requests merged* A total of 19 pull requests were merged for this release. - #27000: REL: Prepare for the NumPy 2.0.1 release [wheel build] - #27001: MAINT: prepare 2.0.x for further development - #27021: BUG: cfuncs.py: fix crash when sys.stderr is not available - #27022: DOC: Fix migration note for ``alltrue`` and ``sometrue`` - #27061: BUG: use proper input and output descriptor in array_assign_subscript... - #27073: BUG: Mirror VQSORT_ENABLED logic in Quicksort - #27074: BUG: Bump Highway to latest master - #27077: BUG: Off by one in memory overlap check - #27122: BUG: Use the new ``npyv_loadable_stride_`` functions for ldexp and... - #27126: BUG: Bump Highway to latest - #27128: BUG: add missing error handling in public_dtype_api.c - #27129: BUG: fix another cast setup in array_assign_subscript - #27130: BUG: Fix building NumPy in FIPS mode - #27131: BLD: update vendored Meson for cross-compilation patches - #27146: MAINT: Scipy openblas 0.3.27.44.4 - #27151: BUG: Do not accidentally store dtype metadata in ``np.save`` - #27195: REV: Revert undef I and document it - #27213: BUG: Fix NPY_RAVEL_AXIS on backwards compatible NumPy 2 builds - #27279: BUG: Fix array_equal for numeric and non-numeric scalar types Cheers, Charles Harris

1 0

iPOPO 3.0.0 released
by Thomas Calmant 26 Aug '24

26 Aug '24

iPOPO v3.0.0 has been released! What is iPOPO ? ============= iPOPO is a Python-based Service-Oriented Component Model (SOCM) based on Pelix, a dynamic service platform. They are inspired by two popular Java technologies for the development of long-lived applications: the iPOJO component model and the OSGi Service Platform. iPOPO enables the development of long-running and modular IT services. It is based on OSGi concepts: - Bundle: a Python module imported using Pelix and associated to a context. A bundle has a life-cycle (install, start, updated, stop, uninstall) - Service: a Python object registered in a service registry, associated to a specification and to properties. - Component: the instance of a class described/manipulated by iPOPO decorators Components are bound together by the specification(s) of the service(s) they provide. The required services are injected into components by iPOPO. For more information, see https://ipopo.readthedocs.io/ iPOPO is released under the terms of Apache Software License 2.0 What's new in 3.0.0 ================ * Dropped support for Python 2.7 and versions earlier than 3.10, it's time to move on * Kept compatibility with iPOPO 1.0 on API level: it is possible to link iPOPO v1 and v3 via Remote Services * Added type hints where possible * Pelix and iPOPO now support types in specifications * Documentation updates * Moved from Travis-CI to GitHub actions to test project against Python 3.10, 3.11 and 3.12 You can take a look at the documentation at https://ipopo.readthedocs.io/ iPOPO is available on PyPI: https://pypi.org/project/iPOPO/ Source is available on GitHub: https://github.com/tcalmant/ipopo Feel free to send feedback on your experience of Pelix/iPOPO, via the mailing lists: * Users list: https://groups.google.com/g/ipopo-users * Developers list: https://groups.google.com/g/ipopo-dev * GitHub discussions: https://github.com/tcalmant/ipopo/discussions Have fun!

1 0

python-oracledb 2.4.1
by Anthony Tuininga 22 Aug '24

22 Aug '24

What is python-oracledb? python-oracledb is a Python extension module that enables access to Oracle Database for Python and conforms to the Python database API 2.0 specifications with a number of enhancements. This module replaces cx_Oracle. Where do I get it? https://pypi.org/project/oracledb/2.4.1/ The easiest method to install/upgrade python-oracledb is via pip as in python -m pip install oracledb --upgrade What's new? This release addresses one reported issue. See the full release notes for all of the details: https://python-oracledb.readthedocs.io/en/latest/release_notes.html#oracled… Please provide any feedback via GitHub issues: https://github.com/oracle/python-oracledb/issues or discussions: https://github.com/oracle/python-oracledb/discussions

1 0

python-oracledb 2.4.0
by Anthony Tuininga 20 Aug '24

20 Aug '24

What is python-oracledb? python-oracledb is a Python extension module that enables access to Oracle Database for Python and conforms to the Python database API 2.0 specifications with a number of enhancements. This module replaces cx_Oracle. Where do I get it? https://pypi.org/project/oracledb/2.4.0/ The easiest method to install/upgrade python-oracledb is via pip as in python -m pip install oracledb --upgrade What's new? This release adds support for Oracle Database 23ai pipelining and corrects a number of reported bugs. See the full release notes for all of the details: https://python-oracledb.readthedocs.io/en/latest/release_notes.html#oracled… Please provide any feedback via GitHub issues: https://github.com/oracle/ python-oracledb/issues or discussions: https://github.com/oracle/python- oracledb/discussions ReplyReply allForward Add reaction

1 0

NumPy 2.1.0 released.
by Charles R Harris 18 Aug '24

18 Aug '24

Hi All On behalf of the NumPy team, I'm pleased to announce the release of NumPy 2.1.0. NumPy 2.1.0 provides support for the upcoming Python 3.13 release and drops support for Python 3.9. In addition to the usual bug fixes and updated Python support, this release helps get NumPy back into its usual release cycle after the extended development of 2.0. Some 469 pull requests were merged for this release, highlights are: - Support for the array-api 2023.12 standard. - Support for Python 3.13. - Preliminary support for free threaded Python 3.13 This release supports Python 3.10-3.13. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.1.0>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v2.1.0>. *Contributors* A total of 110 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - !ogidig5 + - !partev - !vahidmech + - !h-vetinari - Aaron Meurer - Adrin Jalali + - Agriya Khetarpal - Ajay Kumar Janapareddi + - Alex Herbert + - Andras Deak - Andrej Zhilenkov + - Andrew Nelson - Anne Gunn + - Antony Lee - Arnaud Ma + - Arun Kannawadi + - Arun Pa + - Bas van Beek - Ben Woodruff + - Bruno Oliveira + - Carlos Henrique Hermanny Moreira da Silva + - Charles Harris - Chris Sidebottom - Christian Heimes + - Christian Lorentzen - Christopher Sidebottom - Christopher Titchen + - Clément Robert - Cobalt Yang + - Devyani Chavan + - Dimitri Papadopoulos Orfanos - Ebigide Jude + - Eric Xie + - Evgeni Burovski - Fabian Vogt + - Francisco Sousa + - GUAN MING + - Gabriel Fougeron + - Gagandeep Singh - Giovanni Del Monte + - Gonzalo Tornaría + - Gonçalo Bárias + - Hugo van Kemenade - Jakob Stevens Haas + - Jakob Unfried + - James Joseph Thomas + - Jean Lecordier + - Joren Hammudoglu + - Joris Van den Bossche - Julia Poo + - Justus Magin - Jyn Spring 琴春 - KIU Shueng Chuan - Karthik Gangula + - Karthik Kaiplody + - Kevin Sheppard - Kristoffer Pedersen + - Leo Singer - Liang Yan - Liangyu Zhang + - Lucas Colley - Luiz Eduardo Amaral + - Lysandros Nikolaou - Marcel Loose + - Marten van Kerkwijk - Mateusz Sokół - Matt Haberland - Matt Thompson + - Matthew Roeschke + - Matthew Thompson + - Matthias Bussonnier - Matti Picus - Melissa Weber Mendonça - Milica Dančuk + - Moritz Schreiber + - Nathan Goldbaum - Olivier Grisel - Patrick J. Roddy + - Paul Juma Otieno + - Pieter Eendebak - Raghuveer Devulapalli - Ralf Gommers - Raquel Braunschweig + - Robert Kern - Rohit Goswami - Romain Geissler + - Ross Barnowski - Rostan Tabet + - Sam Morley + - Sayed Adel - Sean Cheah - Sebastian Berg - Serge Guelton - Slobodan + - Stefan van der Walt - Thomas A Caswell - Thomas Li - Timo Röhling + - Tsvika Shapira + - Tuhin Sharma + - Tyler Reddy - Victor Eijkhout + - Warren Weckesser - Warrick Ball - Xiangyi Wang + - Yair Chuchem + - Yang Liu + - Yannik Wicke + - Yevhen Amelin + - Yuki K Cheers, Charles Harris

1 0

NumPy 2.1.0rc1 released
by Charles R Harris 11 Aug '24

11 Aug '24

Hi All On behalf of the NumPy team, I'm pleased to announce the release of NumPy 2.1.0rc1. NumPy 2.1.0rc1 provides support for the upcoming Python 3.13 release and drops support for Python 3.9. In addition to the usual bug fixes and updated Python support, it helps get us back into our usual release cycle after the extended development of 2.0. Some 455 pull requests were merged for this release, highlights are: - Support for the array-api 2023.12 standard. - Support for Python 3.13. - Preliminary support for free threaded Python 3.13 This release supports Python 3.10-3.13. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.1.0rc1>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v2.1.0rc1>. *Contributors* A total of 110 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - !ogidig5 + - !partev - !vahidmech + - Aaron Meurer - Adrin Jalali + - Agriya Khetarpal - Ajay Kumar Janapareddi + - Alex Herbert + - Andras Deak - Andrej Zhilenkov + - Andrew Nelson - Anne Gunn + - Antony Lee - Arnaud Ma + - Arun Kannawadi + - Arun Pa + - Bas van Beek - Ben Woodruff + - Bruno Oliveira + - Carlos Henrique Hermanny Moreira da Silva + - Charles Harris - Chris Sidebottom - Christian Heimes + - Christian Lorentzen - Christopher Sidebottom - Christopher Titchen + - Clément Robert - Cobalt Yang + - Devyani Chavan + - Dimitri Papadopoulos Orfanos - Ebigide Jude + - Eric Xie + - Evgeni Burovski - Fabian Vogt + - Francisco Sousa + - GUAN MING + - Gabriel Fougeron + - Gagandeep Singh - Giovanni Del Monte + - Gonzalo Tornaría + - Gonçalo Bárias + - Hugo van Kemenade - Jakob Stevens Haas + - Jakob Unfried + - James Joseph Thomas + - Jean Lecordier + - Joren Hammudoglu + - Joris Van den Bossche - Julia Poo + - Justus Magin - Jyn Spring 琴春 - KIU Shueng Chuan - Karthik Gangula + - Karthik Kaiplody + - Kevin Sheppard - Kristoffer Pedersen + - Leo Singer - Liang Yan - Liangyu Zhang + - Lucas Colley - Luiz Eduardo Amaral + - Lysandros Nikolaou - Marcel Loose + - Marten van Kerkwijk - Mateusz Sokół - Matt Haberland - Matt Thompson + - Matthew Roeschke + - Matthew Thompson + - Matthias Bussonnier - Matti Picus - Melissa Weber Mendonça - Milica Dančuk + - Moritz Schreiber + - Nathan Goldbaum - Olivier Grisel - Patrick J. Roddy + - Paul Juma Otieno + - Pieter Eendebak - Raghuveer Devulapalli - Ralf Gommers - Raquel Braunschweig + - Robert Kern - Rohit Goswami - Romain Geissler + - Ross Barnowski - Rostan Tabet + - Sam Morley + - Sayed Adel - Sean Cheah - Sebastian Berg - Serge Guelton - Slobodan + - Stefan van der Walt - Thomas A Caswell - Thomas Li - Timo Röhling + - Tsvika Shapira + - Tuhin Sharma + - Tyler Reddy - Victor Eijkhout + - Warren Weckesser - Warrick Ball - Xiangyi Wang + - Yair Chuchem + - Yang Liu + - Yannik Wicke + - Yevhen Amelin + - Yuki K Cheers, Charles Harris

1 0

NOSQL API databases
by matteo.guadrini＠hotmail.it 09 Aug '24

09 Aug '24

Hello everybody, this is my first time writing in this section and I hope I’m not out of place. I wanted to propose a new PEP that describes the APIs that a NOSQL database library should have, as I am going to describe below. These types of databases are spreading very quickly and I believe it is necessary to have common interfaces between libraries. In fact, all four types of NOSQL databases have similarities on the most common operations (CRUD operation) and on database level operations. This approach has already been defined for SQL databases in this PEP 249 . The python libraries that follow this PEP are many and have the same interfaces for objects, methods and functions. Many python SQL libraries follow PEP 249, using functions, methods and properties with the nomenclature mentioned therein. This leads to a much easier development and use consistency of these libraries. I wanted to create a similar thing for NOSQL databases although there are many differences between the four types of databases, grouping them into four categories: Column database, such as Apache Cassandra Key/Value database, such as Redis Document database, such as MongoDB Graph database, such as Neo4j These four types of databases have different characteristics on how data are requested and how they are inserted but they also have some common peculiarities. On this assumption I have created a library of interfaces which should represent these common characteristics. I have also written a series of tests to simulate the behavior of existing libraries by encapsulating their methods in interfaces. nosqlapi is an interface/ORM/utility library that is used to write, in turn, python libraries for NOSQL databases, so that they reflect the characteristics of the interfaces and therefore, of the API. In this documentation you will find in detail what I will briefly explain below. Abstract The PEP introduces the API which describes the interfaces and the names of classes, methods, properties and functions that a NOSQL python library should have. The API covers all four types of NOSQL databases. The PEP will also provide extended APIs for the unique peculiarities of each database type. The goal of the API is simplicity and ease of use. Motivation The libraries that exist today concerning NOSQL databases are inconsistent in names. For example, it is easy to find objects dealing with database connections called Database, DatabaseConn and again DBClient. These objects produce the same result: an object that allows you to work directly with the database and its data. These objects are instantiated with the same arguments, but different in names. Some use host for the server name, others use hostname other servers. Same thing for the other arguments. Furthermore, there is no clear distinction between the database layer and the data layer, as is the case for SQL databases. It is therefore necessary for consistency and ease of development and use, to have APIs that allow you to unify all this. Furthermore, instantiating an object that deals at the database level and one at the data level allows for a very clear separation of duties. For this the API will provide a Connection object which will take care of the database level operations, and a Session which will take care of the data instead. Rationale Separating tasks into two different objects has the advantage of isolating programming and execution errors. Another advantage is that a user connecting to a database may not have permissions to work directly on the data. With this separation it is possible to isolate some information to authorized users. The Connection object, will directly deal with working with databases. It will never go into the merits of the data in the database you are working on. The Session object, on the other hand, will work directly with the data that a user can request, insert, modify or delete (CRUD operation). This object will also offer additional methods such as create / modify / delete users, execute Selector and Batch objects. Each response to each operation can be encapsulated in a further object Response, which can contain the result of the operation and even more information. In other languages like Java, a library for nosql database types has been implemented: JNoSQL . Specification The connection to the database will be done through a Connection object. Once this object is instantiated, you will not have an immediate connection to the data, but only to the outermost layer of the server hosting the database, dealing exclusively with the various databases. To get the ability to work on data (CRUD operations) you need to create a new object that will be similar to the Cursor object as far as relational databases are concerned: the Session object. Calling the connect() method of the Connection object will return a Session object . Each operation performed by a Connection object or a Session object should return an object of type Response. This type of object can be instantiated with extra information in addition to the return data, such as the call header or an exit code and relative exception object. Data read operations (_SELECT_s in relational databases) can be implemented directly through a special object (Selector object) that will have a build() method, which will build its query string based on the database dialect. The object can be passed directly to the find() method of the Session object. In addition, there are operations that are found only in one type of database vendor. These operations can be implemented as extensions of the core API classes or, it will be possible to implement a Batch object to pass a series of instructions together with an instance of the Session class. Backwards Compatibility Existing libraries do not have this type of structure and nomenclature to comply with these APIs. In the nosqlapi library there is a decorator that allows you to map the names of existing methods with API compliant names. Potential Problems and their Solutions This section outlines some pitfalls that can arise from using the API. Reference Implementation Nosqlapi documentation site: https://nosqlapi.rtfd.io/ Nosqlapi GitHub: https://github.com/MatteoGuadrini/nosqlapi Nosqlapi production usage: https://github.com/MatteoGuadrini/nosqlapi/blob/main/tests/test_real_produc…

1 0

[RELEASE] Python 3.12.5 released
by Thomas Wouters 07 Aug '24

07 Aug '24

Python 3.12.5 is now available: https://www.python.org/downloads/release/python-3125/ This is the fifth maintenance release of Python 3.12 Python 3.12 is the newest major release of the Python programming language, and it contains many new features and optimizations. 3.12.5 is the latest maintenance release, containing more than 250 bugfixes, build improvements and documentation changes since 3.12.4. This version of Python 3.12 also comes with pip 24.2 by default. *However, due to an incompatibility with older macOS versions, macOS 10.9 through 10.12 will downgrade their version of pip to 24.1.2 during the installation process* (in the Install Certificates step). See the installer ReadMe and the pip issue on the matter <https://github.com/pypa/pip/issues/12901> for more information. Versions of macOS older than 10.13 haven’t been supported by Apple since 2019, and maintaining support for them is becoming increasingly difficult. While this release of 3.12 still supports them, *it is likely that we will be forced to drop support for macOS 10.12 and older in a future 3.12 release*. (Python 3.13 has already dropped support for them.) <https://discuss.python.org/t/python-3-12-5-now-available/60219#p-182613-maj…>Major new features of the 3.12 series, compared to 3.11 <https://discuss.python.org/t/python-3-12-5-now-available/60219#p-182613-new…>New features - More flexible f-string parsing <https://docs.python.org/3.12/whatsnew/3.12.html#pep-701-syntactic-formaliza…>, allowing many things previously disallowed (PEP 701 <https://peps.python.org/pep-0701/>). - Support for the buffer protocol <https://docs.python.org/3.12/whatsnew/3.12.html#pep-688-making-the-buffer-p…> in Python code (PEP 688 <https://peps.python.org/pep-0688/>). - A new debugging/profiling API <https://docs.python.org/3.12/whatsnew/3.12.html#pep-669-low-impact-monitori…> (PEP 669 <https://peps.python.org/pep-0669/>). - Support for isolated subinterpreters <https://docs.python.org/3.12/whatsnew/3.12.html#pep-684-a-per-interpreter-g…> with separate Global Interpreter Locks (PEP 684 <https://peps.python.org/pep-0684>). - Even more improved error messages <https://docs.python.org/3.12/whatsnew/3.12.html#improved-error-messages>. More exceptions potentially caused by typos now make suggestions to the user. - Support for the Linux perf profiler <https://docs.python.org/3.12/howto/perf_profiling.html> to report Python function names in traces. - Many large and small performance improvements <https://docs.python.org/3.12/whatsnew/3.12.html#optimizations> (like PEP 709 <https://peps.python.org/pep-0709/> and support for the BOLT binary optimizer), delivering an estimated 5% overall performance improvement. <https://discuss.python.org/t/python-3-12-5-now-available/60219#p-182613-typ…>Type annotations - New type annotation syntax <https://docs.python.org/3.12/whatsnew/3.12.html#pep-695-type-parameter-synt…> for generic classes (PEP 695 <https://peps.python.org/pep-0695/>). - New override decorator <https://docs.python.org/3.12/whatsnew/3.12.html#pep-698-override-decorator-…> for methods (PEP 698 <https://peps.python.org/pep-0698>). <https://discuss.python.org/t/python-3-12-5-now-available/60219#p-182613-dep…> Deprecations - The deprecated wstr and wstr_length members of the C implementation of unicode objects were removed, per PEP 623 <https://peps.python.org/pep-0623/>. - In the unittest module, a number of long deprecated methods and classes were removed. (They had been deprecated since Python 3.1 or 3.2). - The deprecated smtpd and distutils modules have been removed (see PEP 594 <https://peps.python.org/pep-0594/> and PEP 632 <https://peps.python.org/pep-0632/>. The setuptools package continues to provide the distutils module. - A number of other old, broken and deprecated functions, classes and methods <https://docs.python.org/3.12/whatsnew/3.12.html#removed> have been removed. - Invalid backslash escape sequences in strings now warn with SyntaxWarning instead of DeprecationWarning, making them more visible. (They will become syntax errors in the future.) - The internal representation of integers has changed in preparation for performance enhancements. (This should not affect most users as it is an internal detail, but it may cause problems for Cython-generated code.) For more details on the changes to Python 3.12, see What’s new in Python 3.12 <https://docs.python.org/3.12/whatsnew/3.12.html>. <https://discuss.python.org/t/python-3-12-5-now-available/60219#p-182613-mor…>More resources - Online Documentation <https://docs.python.org/3.12/>. - PEP 693 <https://www.python.org/dev/peps/pep-0693/>, the Python 3.12 Release Schedule. - Report bugs via GitHub Issues <https://github.com/python/cpython/issues>. - Help fund Python directly <https://www.python.org/psf/donations/python-dev/> or via GitHub Sponsors <https://github.com/sponsors/python>, and support the Python community <https://www.python.org/psf/donations/>. <https://discuss.python.org/t/python-3-12-5-now-available/60219#p-182613-enj…>Enjoy the new releases Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Your release team, Thomas Wouters Łukasz Langa Ned Deily Steve Dower -- Thomas Wouters <thomas(a)python.org>

1 0

[RELEASE] Python 3.13.0 release candidate 1 released
by Thomas Wouters 01 Aug '24

01 Aug '24

Python 3.13 *release candidate 1* is now available. https://www.python.org/downloads/release/python-3130rc1/ <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…>This is the first release candidate of Python 3.13.0 This release, *3.13.0rc1*, is the penultimate release preview. Entering the release candidate phase, only reviewed code changes which are clear bug fixes are allowed between this release candidate and the final release. The second candidate (and the last planned release preview) is scheduled for Tuesday, 2024-09-03, while the official release of 3.13.0 is scheduled for Tuesday, 2024-10-01. There will be *no ABI changes* from this point forward in the 3.13 series, and the goal is that there will be as few code changes as possible. <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…>Call to action We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.13 compatibilities during this phase, and where necessary publish Python 3.13 wheels on PyPI to be ready for the final release of 3.13.0. Any binary wheels built against Python 3.13.0rc1 *will work* with future versions of Python 3.13. As always, report any issues to the Python bug tracker <https://github.com/python/cpython/issues>. Please keep in mind that this is a preview release and while it’s as close to the final release as we can get it, its use is *not* recommended for production environments. <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…>Core developers: time to work on documentation now - Are all your changes properly documented? - Are they mentioned in What’s New <https://docs.python.org/3.13/whatsnew/3.13.html>? - Did you notice other changes you know of to have insufficient documentation? <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…>Major new features of the 3.13 series, compared to 3.12 Some of the new major new features and changes in Python 3.13 are: <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…>New features - A new and improved interactive interpreter <https://docs.python.org/3.13/whatsnew/3.13.html#a-better-interactive-interp…>, based on PyPy <https://pypy.org>’s, featuring multi-line editing and color support, as well as colorized exception tracebacks <https://docs.python.org/3.13/whatsnew/3.13.html#improved-error-messages> . - An *experimental* free-threaded build mode <https://docs.python.org/3.13/whatsnew/3.13.html#free-threaded-cpython>, which disables the Global Interpreter Lock, allowing threads to run more concurrently. The build mode is available as an experimental feature in the Windows and macOS installers as well. - A preliminary, *experimental* JIT <https://docs.python.org/3.13/whatsnew/3.13.html#experimental-jit-compiler>, providing the ground work for significant performance improvements. - The locals() builtin function (and its C equivalent) now has well-defined semantics when mutating the returned mapping <https://docs.python.org/3.13/whatsnew/3.13.html#defined-mutation-semantics-…>, which allows debuggers to operate more consistently. - The (cyclic) garbage collector is now incremental <https://docs.python.org/3.13/whatsnew/3.13.html#incremental-garbage-collect…>, which should mean shorter pauses for collection in programs with a lot of objects. - A modified version of mimalloc <https://github.com/microsoft/mimalloc> is now included, optional but enabled by default if supported by the platform, and required for the free-threaded build mode. - Docstrings now have their leading indentation stripped <https://docs.python.org/3.13/whatsnew/3.13.html#other-language-changes>, reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.) - The dbm module <https://docs.python.org/3.13/library/dbm.html> has a new dbm.sqlite3 backend <https://docs.python.org/3.13/whatsnew/3.13.html#dbm> that is used by default when creating new files. - The minimum supported macOS version was changed from 10.9 to *10.13 (High Sierra)*. Older macOS versions will not be supported going forward. - WASI is now a Tier 2 supported platform <https://peps.python.org/pep-0011/#tier-2>. Emscripten is no longer an officially supported platform <https://peps.python.org/pep-0011/#no-longer-supported-platforms> (but Pyodide <https://pyodide.org> continues to support Emscripten). - iOS is now a Tier 3 supported platform <https://peps.python.org/pep-0730/>, with Android on the way as well <https://peps.python.org/pep-0738/>. <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…> Typing - Support for type defaults in type parameters <https://peps.python.org/pep-0696/>. - A new type narrowing annotation <https://peps.python.org/pep-0742/>, typing.TypeIs. - A new annotation for read-only items in TypeDicts <https://peps.python.org/pep-0705/>. - A new annotation for marking deprecations in the type system <https://peps.python.org/pep-0702>. <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…>Removals and new deprecations - PEP 594 (Removing dead batteries from the standard library) <https://peps.python.org/pep-0594/> scheduled removals of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3. - Many other removals <https://docs.python.org/3.13/whatsnew/3.13.html#removed> of deprecated classes, functions and methods in various standard library modules. - C API removals <https://docs.python.org/3.13/whatsnew/3.13.html#id10> and deprecations <https://docs.python.org/3.13/whatsnew/3.13.html#id9>. (Some removals present in alpha 1 were reverted in alpha 2, as the removals were deemed too disruptive at this time.) - New deprecations <https://docs.python.org/3.13/whatsnew/3.13.html#deprecated>, most of which are scheduled for removal from Python 3.15 or 3.16. (Hey, *fellow core developer,* if a feature you find important is missing from this list, let Thomas know <thomas(a)python.org>.) For more details on the changes to Python 3.13, see What’s new in Python 3.13 <https://docs.python.org/3.13/whatsnew/3.13.html>. The next pre-release of Python 3.13 will be 3.13.0rc2, *the final release candidate*, currently scheduled for 2024-09-03. <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…>More resources - Online Documentation <https://docs.python.org/3.13/> - PEP 719 <https://peps.python.org/pep-0719/>, 3.13 Release Schedule - Report bugs at Issues · python/cpython · GitHub <https://github.com/python/cpython/issues>. - Help fund Python directly <https://www.python.org/psf/donations/python-dev/> (or via GitHub Sponsors <https://github.com/sponsors/python>), and support the Python community <https://www.python.org/psf/donations/>. <https://discuss.python.org/t/python-3-13-0-release-candidate-1-released/597…>Enjoy the new releases Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Your release team, Thomas Wouters Łukasz Langa Ned Deily Steve Dower -- Thomas Wouters <thomas(a)python.org>

1 0