gh-60712: Include the "object" type in the lists of documented types (GH-103036)
* add test for the predefined object's attributes
* Include the "object" type in the lists of documented types
* remove 'or' from augment tuple
* 📜🤖 Added by blurb_it.
* Add cross-reference to news
* Fix format for the function parameter
* Add space
* add reference for the 'object'
* add reference for NotImplemented
* Change ref:`string <textseq>` as class:`str`
* remove hyphen from `newly-created`
* Update Doc/reference/datamodel.rst
'dictionaries' to 'dict'
* Update predefined attribute types in testPredefinedAttrs
* Change `universal type` as `top type`
* Don't mention about the top type
* Update the description of richcmpfuncs
* Update Doc/library/stdtypes.rst
* Revert: Hierarchy Section in Data Model Documentation
* Revert to original explanations of __new__ and __init__ methods in datamodel.rst for improved clarity.
* Update Doc/reference/datamodel.rst
* Remove blank line
* Use ref:`str <textseq>` instead of :class:`str
* Revert changes the description of Other Built-in Types in stdtypes.rst
* Update Doc/reference/datamodel.rst
---------
(cherry picked from commit 4f826214b3)
Co-authored-by: Furkan Onder <furkanonder@protonmail.com>
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
Co-authored-by: Éric <merwok@netwok.org>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Use same names for parameters to avoid triggering a race-condition in Sphinx
that causes non-deterministic output.
(cherry picked from commit 24cf867bed)
Co-authored-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
* Remove the equivalence with real+imag*1j which can be incorrect in corner
cases (non-finite numbers, the sign of zeroes).
* Separately document the three roles of the constructor: parsing a string,
converting a number, and constructing a complex from components.
* Document positional-only parameters of complex(), float(), int() and bool()
as positional-only.
* Add examples for complex() and int().
* Specify the grammar of the string for complex().
* Improve the grammar of the string for float().
* Describe more explicitly the behavior when real and/or imag arguments are
complex numbers. (This will be deprecated in future.)
(cherry picked from commit ec1ba26460)
DOCS: Suggest always calling exec with a globals argument and no locals argument (GH-119235)
Many users think they want a locals argument for various reasons but they do not
understand that it makes code be treated as a class definition. They do not want
their code treated as a class definition and get surprised. The reason not
to pass locals specifically is that the following code raises a `NameError`:
```py
exec("""
def f():
print("hi")
f()
def g():
f()
g()
""", {}, {})
```
The reason not to leave out globals is as follows:
```py
def t():
exec("""
def f():
print("hi")
f()
def g():
f()
g()
""")
```
(cherry picked from commit 7e1a130b8f)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Also mention that the 'expression' parameter can be a string.
(cherry picked from commit a71e32ce8e)
Co-authored-by: Erlend E. Aasland <erlend@python.org>
Added to repr entry in Doc/library/functions.rst.
---------
(cherry picked from commit 5770006ffa)
Co-authored-by: Oh seungmin <tmdals179@gmail.com>
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
gh-114070: correct the specification of ``digit`` in the float() docs (GH-114080)
(cherry picked from commit 4f24b92aa0)
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
gh-59254: mention in open() doc that line buffering is for writing (GH-112318)
(cherry picked from commit fafae08cc7)
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
gh-110631: Fix reST indentation in `Doc/library` (GH-110685)
Fix wrong indentation in the Doc/library dir.
(cherry picked from commit bb7923f556)
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
gh-107755: Document the correct default value of slice step (GH-107756)
Document the correct default value of slice step.
(cherry picked from commit 9bf350b066)
Co-authored-by: wim glenn <hey@wimglenn.com>
gh-107662: Switch 'any' and 'anext' in functions.rst (GH-107663)
Order was reversed in index at top, not in body.
(cherry picked from commit 9ebc6ecbc3)
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
gh-101880: add link to object.__hash__() in hash() builtin documentation (GH-101883)
(cherry picked from commit ec7180bd1b)
Co-authored-by: Owain Davies <116417456+OTheDev@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>
- Remove first link to lexical definition of integer literal, since it
doesn't apply (differs in handling of leading zeros, base needs to be
explicitly specified, unicode digits are allowed)
- Better describe handling of leading zeros, unicode digits, underscores
- Base 0 does not work exactly as like a code literal, since it allows
Unicode digits. Link code literal to lexical definition of integer
literal.
All the arguments are positional-only.
The current status after #99476 seems to be to not use positional-only
markers in documentation, hence I've simply removed it.
