Major new features of the 3.15 series, compared to 3.14
Python 3.15 is still in development. This release, 3.15.0a1, is the first of seven planned alpha releases.
Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process.
During the alpha phase, features may be added up until the start of the beta phase (2026-05-05) and, if necessary, may be modified or deleted up until the release candidate phase (2026-07-28). Please keep in mind that this is a preview release and its use is not recommended for production environments.
Many new features for Python 3.15 are still being planned and written. Among the new major new features and changes so far:
PEP 799: A dedicated profiling package for Python profiling tools
PEP 686: Python now uses UTF-8 as the default encoding
PEP 782: A new PyBytesWriter C API to create a Python bytes object
And hence not only at substantiated times, upon well known separate feeding-grounds, could Ahab hope to encounter his prey; but in crossing the widest expanses of water between those grounds he could, by his art, so place and time himself on his way, as even then not to be wholly without prospect of a meeting.
Enjoy the new release
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 organisation contributions to the Python Software Foundation.
Regards from Helsinki before the first PyCon Finland in 9 years,
On that topic, I find that the C API documentation is lacking information about the allocation strategy. It is important for the caller to know if the PyBytesWriter APIs may overallocate or not, as that changes the performance profle.
And if the answer is âit might, but it might not sometimesâ, is that still useful? Some things (particularly performance related) really just need to be profiled, and if you find a way to improve it, not having documented it means we can just apply the improvement.
list construction using repeated append or extend calls is guaranteed to be O(final length) on pretty much any released Python version. You can rely on it, though it doesnât appear to be officially documented
the C++ reference for std::vectorguarantees that âinsertion or removal of elements at the endâ is amortized constant O(1); and thatâs for a language with a non-trivial number of production-grade implementations
If PyBytesWriter doesnât specify anything about the expected performance of common usage patterns, then it might not be much more useful than repeated calls to PyBytes_Concat.
C++ specifically designs their container types around algorithm type, though (hence vector, list, set, unordered_set), whereas we define ours more around semantics. So yes, they guarantee things, but also intentionally pass the burden of choice onto their users.
Benchmark your scenario and find out? In another runtime that uses the same native API as CPython, you may find different results. While C++ guarantees O() behaviour across implementations, Python generally does not,[1] but at the level this works at youâre basically out of the N and into the coefficients/constant anyway.
We want our users to be able to choose the API based on it closely matching their scenario, not based on performance characteristics. We also want to preserve our ability to change the internal working of our APIs to be more efficient without breaking user expectations. Both of those lead us towards not making algorithmic behaviour part of the contract.
Notable exceptions being dict lookup and string slicing, and even then some implementations ignore us on string slicing and let it be non-constant and we donât really mind. âŠď¸
Well, the scenario here is efficient construction of bytes objects, with as few memory copies and reallocations as possible. Otherwise, existing C API functions such as PyBytes_Concat or PyBytes_Join[1] can be wrangled relatively easily.
If they become more efficient then certainly they wouldnât break existing expectations around efficiency?
the former already part of the stable ABI, the latter not but it probably could âŠď¸
We need to reserve the right to make them less efficient but still correct, otherwise weâll force ourselves to deprecate the entire function and delay other improvements for the deprecation period. It goes both ways.
PyBytes_Concat and PyBytes_Join are best for cases where you already have a bytes object. PyBytesWriter is best for cases where you have the data, but not a Python object representing it.
Less efficient than what? Even if you refuse to document efficiency guarantees, projects will critically rely on the concrete performance characteristics of this API. What do you think happens if incrementally building a 10MB bytes object suddenly becomes O(final length^2) instead of O(final length)? Suddenly youâre breaking potentially important use cases for third-party projects.
If the list object in the next Python version had non-constant amortized performance for append then it would be a severe regression and deserve an immediate bugfix.
re: PyBytes_Concat and PyBytes_Join vs PyBytesWriter multiple contributors have built performance benchmarks to check / validate performance changes in transitioning to PyBytesWriter:
