gh-129020: Remove ambiguous sentence from `tokenize.untokenize` docs (GH-129021)
(cherry picked from commit bca35f0e78)
Co-authored-by: Tomas R <tomas.roun8@gmail.com>
gh-128017: Make a note that sys variables are read-only (GH-128887)
(cherry picked from commit 313b96eb8b)
Co-authored-by: Srinivas Reddy Thatiparthy (తాటిపర్తి శ్రీనివాస్ రెడ్డి) <thatiparthysreenivas@gmail.com>
gh-97850: Suggest `TraversableResources` as the alternative for `ResourceLoader` (GH-128601)
Suggest TraversableResources as the alternative for ResourceLoader.
Previously, ResourceReader was the suggested alternative, but it
is itself deprecated in favour of TraversableResources.
(cherry picked from commit 256d6d2131)
Co-authored-by: Tomas R <tomas.roun8@gmail.com>
gh-67206: Document that `string.printable` is not printable in the POSIX sense (GH-128820)
(cherry picked from commit d906bde250)
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Fix a "doctest" block in `Doc/library/turtle.rst` (GH-128831)
(cherry picked from commit 1598e18a65)
Co-authored-by: Rafael Fontenelle <rffontenelle@users.noreply.github.com>
(cherry picked from commit a0088b40bb)
Co-authored-by: Erlend E. Aasland <erlend@python.org>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Specify that it is valid for floats and ints with 'd' presentation and an error otherwise.
---------
(cherry picked from commit e2325c9db0)
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
link to the correct output method in documentation (GH-127857)
(cherry picked from commit 11ff3286b7)
Co-authored-by: Viktor Kálmán <kviktor@users.noreply.github.com>
Fix a crash caused by immortal interned strings being shared between
sub-interpreters that use basic single-phase init. In that case, the string
can be used by an interpreter that outlives the interpreter that created and
interned it. For interpreters that share obmalloc state, also share the
interned dict with the main interpreter.
This is an un-revert of gh-124646 that then addresses the Py_TRACE_REFS
failures identified by gh-124785 (i.e. backporting gh-125709 too).
(cherry picked from commit f2cb399470, AKA gh-124865)
Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
The CPython uses _Py_dg_dtoa(), which does rounding to nearest with half
to even tie-breaking rule.
If that functions is unavailable, PyOS_double_to_string() fallbacks to
system snprintf(). Since CPython 3.12, build requirements include C11
compiler *and* support for IEEE 754 floating point numbers (Annex F).
This means that FE_TONEAREST macro is available and, per default,
printf-like functions should use same rounding mode as _Py_dg_dtoa().
(cherry picked from commit 7d7d56d8b1)
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
gh-127303: Add docs for token.EXACT_TOKEN_TYPES (GH-127304)
---------
(cherry picked from commit dd3a87d2a8)
Co-authored-by: Илья Любавский <100635212+lubaskinc0de@users.noreply.github.com>
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
Co-authored-by: Tomas R. <tomas.roun8@gmail.com>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Improve `pathname2url()` and `url2pathname()` docs (GH-127125)
These functions have long sown confusion among Python developers. The
existing documentation says they deal with URL path components, but that
doesn't fit the evidence on Windows:
>>> pathname2url(r'C:\foo')
'///C:/foo'
>>> pathname2url(r'\\server\share')
'////server/share' # or '//server/share' as of quite recently
If these were URL path components, they would imply complete URLs like
`file://///C:/foo` and `file://////server/share`. Clearly this isn't right.
Yet the implementation in `nturl2path` is deliberate, and the
`url2pathname()` function correctly inverts it.
On non-Windows platforms, the behaviour until quite recently is to simply
quote/unquote the path without adding or removing any leading slashes. This
behaviour is compatible with *both* interpretations -- 1) the value is a
URL path component (existing docs), and 2) the value is everything
following `file:` (this commit)
The conclusion I draw is that these functions operate on everything after
the `file:` prefix, which may include an authority section. This is the
only explanation that fits both the Windows and non-Windows behaviour.
It's also a better match for the function names.
(cherry picked from commit 307c633586)
Co-authored-by: Barney Gale <barney.gale@gmail.com>
* Name without a PATHEXT extension is only searched if the mode does not
include X_OK.
* Support multi-component PATHEXT extensions (e.g. ".foo.bar").
* Support files without extensions in PATHEXT contains dot-only extension
(".", "..", etc).
* Support PATHEXT extensions that end with a dot (e.g. ".foo.").
(cherry picked from commit 8899e85de1)
It now returns multiple era description segments separated by semicolons.
Previously it only returned the first segment on platforms with Glibc.
(cherry picked from commit 4803cd0244)
Added a warning to the urljoin docs, indicating that it is not safe to use with attacker controlled URLs (GH-126659)
This was flagged to me at a party today by someone who works in red-teaming as a frequently encountered footgun. Documenting the potentially unexpected behavior seemed like a good place to start.
(cherry picked from commit d6bcc154e9)
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
gh-123832: Adjust `socket.getaddrinfo` docs for better POSIX compliance (GH-126182)
* gh-123832: Adjust `socket.getaddrinfo` docs for better POSIX compliance
This changes nothing changes for CPython supported platforms,
but hints how to deal with platforms that stick to the letter of
the spec.
It also marks `socket.getaddrinfo` as a wrapper around `getaddrinfo(3)`;
specifically, workarounds to make the function work consistently across
platforms are out of scope in its code.
Include wording similar to the POSIX's “by providing options and by
limiting the returned information”, which IMO suggests that the
hints limit the resulting list compared to the defaults, *but* can
be interpreted differently. Details are added in a note.
Specifically say that this wraps the underlying C function. So, the
details are in OS docs. The “full range of results” bit goes away.
Use `AF_UNSPEC` rather than zero for the *family* default, although
I don't think a system where it's nonzero would be very usable.
Suggest setting proto and/or type (with examples, as the appropriate
values aren't obvious). Say why you probably want to do that that
on all systems; mention the behavior on the “letter of the spec”
systems.
Suggest that the results should be tried in order, which is,
AFAIK best practice -- see RFC 6724 section 2, and its predecessor
from 2003 (which are specific to IP, but indicate how people use this):
> Well-behaved applications SHOULD iterate through the list of
> addresses returned from `getaddrinfo()` until they find a working address.
(cherry picked from commit ff0ef0a54b)
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
