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>
gh-118633: Add warning regarding the unsafe usage of eval and exec (GH-118437)
* Add warning regarding the unsafe usage of eval
* Add warning regarding the unsafe usage of exec
* Move warning under parameters table
* Use suggested shorter text
* Use suggested shorter text
* Improve wording as suggested
---------
(cherry picked from commit 00e5ec0d35)
Co-authored-by: Daniel Ruf <daniel@daniel-ruf.de>
Co-authored-by: Kirill Podoprigora <kirill.bast9@mail.ru>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Fix typo in ``Doclibrary/functions.rst`` (GH-125327)
(cherry picked from commit 76b29d271b)
Co-authored-by: Rafael Fontenelle <rffontenelle@users.noreply.github.com>
The term "free variable" has unfortunately become genuinely
ambiguous over the years (presumably due to the names of
some relevant code object instance attributes).
While we can't eliminate that ambiguity at this late date, we can
at least alert people to the potential ambiguity by describing
both the formal meaning of the term and the common
alternative use as a direct synonym for "closure variable".
---------
(cherry picked from commit 27390990fa)
Co-authored-by: Alyssa Coghlan <ncoghlan@gmail.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
* 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)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
When updating the new exec note added in gh-119235 as part of the
PEP 667 general docs PR, I suggested a workaround that isn't valid.
The first half of the note is still reasonable, so just omit the invalid text.
(cherry picked from commit 31d61a75c9)
Co-authored-by: Alyssa Coghlan <ncoghlan@gmail.com>
* expand on What's New entry for PEP 667 (including porting notes)
* define 'optimized scope' as a glossary term
* cover comprehensions and generator expressions in locals() docs
* review all mentions of "locals" in documentation (updating if needed)
* review all mentions of "f_locals" in documentation (updating if needed)
(cherry picked from commit e870c852c0)
Co-authored-by: Alyssa Coghlan <ncoghlan@gmail.com>
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>
* 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.