gh-85583: Add an overview of formatted string literals (f-strings) to ``str`` (GH-132689)
(cherry picked from commit fee808936f)
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
gh-131885: Document that `dict.setdefault` and `dict.get` take no keyword arguments (GH-128208)
(cherry picked from commit edfbd8c062)
Co-authored-by: Adam Dangoor <adamdangoor@gmail.com>
gh-131417: Mention asyncio Future and Task in docs for generic classes list (GH-131422)
Mention asyncio Future and Task in docs for generic classes list
(cherry picked from commit 61b4b2c57c)
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
These references to an `__iter__` method mean `object.__iter__`, not `iterator.__iter__`.
(cherry picked from commit 4d3a7ea354)
Co-authored-by: Yuki Kobayashi <drsuaimqjgar@gmail.com>
We had the definition of what makes a character "printable" documented in three places, giving two different definitions.
The definition in the comment on `_PyUnicode_IsPrintable` was inverted; correct that.
With that correction, the two definitions turn out to be equivalent -- but to confirm that, you have to go look up, or happen to know, that those are the only five "Other" categories and only three "Separator" categories in the Unicode character database. That makes it hard for the reader to tell whether they really are the same, or if there's some subtle difference in the intended semantics.
Fix that by cutting the C API docs' and the C comment's copies of the subtle details, in favor of referring to the Python-level docs. That ensures it's explicit that these are all meant to agree, and also lets us concentrate improvements to the wording in one place.
Speaking of which, borrow some ideas from the C comment, along with other tweaks, to hopefully add a bit more clarity to that one newly-centralized copy in the docs.
Also add a thorough test that the implementation agrees with this definition.
Author: Greg Price <gnprice@gmail.com>
Co-authored-by: Greg Price <gnprice@gmail.com>
(cherry picked from commit 3402e133ef)
gh-116938: Fix `dict.update` docstring and remove erraneous full stop from `dict` documentation (GH-125421)
(cherry picked from commit 5527c4051c)
Co-authored-by: Prometheus3375 <35541026+Prometheus3375@users.noreply.github.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
gh-122982: Extend the deprecation period for bool inversion by two years (GH-123306)
(cherry picked from commit 249b083ed8)
Co-authored-by: Kirill Podoprigora <kirill.bast9@mail.ru>
Update example of str.split, bytes.split (GH-121287)
In `{str,bytes}.strip(chars)`, multiple characters are not treated as a
prefix/suffix, but as individual characters. This may make users confuse
whether `split` has similar behavior.
Users may incorrectly expect that
`'Good morning, John.'.split(', .') == ['Good', 'morning', 'John']`
Adding a bit of clarification in the doc.
(cherry picked from commit 892e3a1b70)
Co-authored-by: Yuxin Wu <ppwwyyxxc@gmail.com>
Co-authored-by: Yuxin Wu <ppwwyyxx@users.noreply.github.com>
* Uncomment builtin removal in pairindextypes
* Use new-style index directive ('builtin') - C API
* Use new-style index directive ('builtin') - Extending
* Use new-style index directive ('builtin') - Library
* Use new-style index directive ('builtin') - Reference
* Use new-style index directive ('builtin') - Tutorial
* Uncomment object removal in pairindextypes
* Use new-style index directive ('object') - C API
* Use new-style index directive ('object') - Library
* Use new-style index directive ('object') - Reference
* Use new-style index directive ('object') - Tutorial
* Use new-style index directive ('module') - C API
* Use new-style index directive ('module') - Library
* Use new-style index directive ('module') - Reference
* Use new-style index directive ('module') - Tutorial
* Uncomment module removal in pairindextypes
* Use new-style index directive ('module') - C API
* Use new-style index directive ('module') - Library
* Use new-style index directive ('module') - Reference
The bitwise inversion operator on bool returns the bitwise inversion of the
underlying int value; i.e. `~True == -2` such that `bool(~True) == True`.
It's a common pitfall that users mistake `~` as negation operator and actually
want `not`. Supporting `~` is an artifact of bool inheriting from int. Since there
is no real use-case for the current behavior, let's deprecate `~` on bool and
later raise an error. This removes a potential source errors for users.
Full reasoning: https://github.com/python/cpython/issues/82012#issuecomment-1258705971
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
