Co-authored-by: Erlend E. Aasland <erlend@python.org>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
- Create a new page for thread safety notes for built-in types
- Move thread safety notes for `list` into the new page
- Move thread safety notes for `dict` into the new page
---------
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Expose the %d substitution as the tkinter.Event attributes:
* "detail" for Enter, Leave, FocusIn, FocusOut, and ConfigureRequest events
* "user_data" for virtual events
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* introduce executable specific linker flags
Add PY_CORE_EXE_LDFLAGS and EXE_LDFLAGS which stores executable specific
LDFLAGS, replacing PY_CORE_LDFLAGS for building
executable targets.
If PY_CORE_EXE_LDFLAGS / EXE_LDFLAGS is not provided, then it defaults
to the value of PY_CORE_LDFLAGS which is the existing behaviour.
If both flags are supplied, and there is a need
to distinguish between executable and shared specific LDFLAGS,
in particular, PY_CORE_LDFLAGS should contain the shared specific LDFLAGS.
* documentation for new linker flags
* update Misc folder documentation
* Update Makefile.pre.in
Co-authored-by: Victor Stinner <vstinner@python.org>
---------
Co-authored-by: Filipe Laíns <filipe.lains@gmail.com>
Co-authored-by: Victor Stinner <vstinner@python.org>
Co-authored-by: Filipe Laíns <lains@riseup.net>
Deprecate PEP-456 [1] support for providing an external definition
of the string hashing scheme. Removal is scheduled for Python 3.19.
Previously, embedders could define the ``Py_HASH_ALGORITHM`` macro to be
``Py_HASH_EXTERNAL`` [2] to indicate that the hashing scheme was provided
externally but this feature was undocumented, untested and most likely
unused.
[1]: https://peps.python.org/pep-0456/
[2]: https://peps.python.org/pep-0456/#hash-function-selection
The documentation incorrectly stated that numeric group arguments
must be in the range [1..99]. This limit was removed in Python 3.5
(bpo-22437). Replace with "a positive integer" since the next
sentence already documents the IndexError for out-of-range values.
* Docs: a start on an 'improve this page' feature
* pr feedback: simplify the link, and don't scare people with the cla
* pr feedback answered
- use the actual page URL
- tighten the wording
* fix the improve link on the improve page
* news item
* Update Doc/improve-page.rst
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
* fix whitespace
* A nojs version of the page
* comments to help people keep the two pages in sync
* protect against XSS
* use template for issues from the nojs page
* use the template from the JS page as well
* give the docs issue template a fillable description field
* ugh, getting sloppy
* remove more sloppiness
---------
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Add TYPE_FROZENDICT to the marshal module.
Add C API functions:
* PyAnyDict_Check()
* PyAnyDict_CheckExact()
* PyFrozenDict_Check()
* PyFrozenDict_CheckExact()
* PyFrozenDict_New()
Add PyFrozenDict_Type C type.
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Adam Johnson <me@adamj.eu>
Co-authored-by: Benedikt Johannes <benedikt.johannes.hofer@gmail.com>
* %D support for strptime, including test and Doc update
* additional %D test
* change documentation example date for %D so it is more legible to non-US readers
* change testing date for %D so it is more legible to non-US readers
* mv News blurb to Library, consistent with previous %F change
* change invalid format code from %D to C-standard unused %!
* Fix erroneous and misleading example Doc to %y from %Y, use correct C99+ definition for C99 %D; update additional tests
---------
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Adds `prefixmatch` APIs to the re module as an alternate name for our long existing `match` APIs to help alleviate a common Python confusion for those coming from other languages regular expression libraries.
These alleviate common confusion around what "match" means as Python is different than other popular languages regex libraries in our use of the term as an API name. The original `match` names are **NOT being deprecated**. Source tooling like linters, IDEs, and LLMs could suggest using `prefixmatch` instead of match to improve code health and reduce cognitive burden of understanding the intent of code when configured for a modern minimum Python version.
See the documentation changes for a better description.
Discussions took place in the PR, in the issue, and finally at https://discuss.python.org/t/add-re-prefixmatch-deprecate-re-match/105927
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
