This is to allow the `dataclasses.make_dataclass` infrastructure to be used with another decorator that's compliant with `typing.dataclass_transform`. The new `decorator` argument to `dataclasses.make_dataclass` is `dataclasses.dataclass`, which used to be hard coded.
* Setting the __module__ attribute for a class now removes the
__firstlineno__ item from the type's dict.
* The _collections_abc and _pydecimal modules now completely replace the
collections.abc and decimal modules after importing them. This
allows to get the source of classes and functions defined in these
modules.
* inspect.findsource() now checks whether the first line number for a
class is out of bound.
- Move "versionchanged" notes that apply to the whole class to the
end of the class docs
- Remove or move notes next to the method list that apply to individual
methods.
- Mark up parameters using the appropriate syntax
- Do not capitalize "boolean"
- Shorten some text
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Change the default multiprocessing start method away from fork to forkserver or spawn on the remaining platforms where it was fork. See the issue for context. This makes the default far more thread safe (other than for people spawning threads at import time... - don't do that!).
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
To recap: the objective is to make starred expressions valid in `subscription`,
which is used for generics: `Generic[...]`, `list[...]`, etc.
What _is_ gramatically valid in such contexts? Seemingly any of the following.
(At least, none of the following throw `SyntaxError` in a 3.12.3 REPL.)
Generic[x]
Generic[*x]
Generic[*x, y]
Generic[y, *x]
Generic[x := 1]
Generic[x := 1, y := 2]
So introducting
flexible_expression: expression | assignment_expression | starred_item
end then switching `subscription` to use `flexible_expression` sorts that.
But then we need to field `yield` - for which any of the following are
apparently valid:
yield x
yield x,
yield x, y
yield *x,
yield *x, *y
Introducing a separate `yield_list` is the simplest way I've been figure out to
do this - separating out the special case of `starred_item ,`.
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Using a standard library class makes this test difficult to maintain
as other tests and other parts of the stdlib may create subclasses,
which may still be alive when this test runs depending on GC timing.
* For-else deserves its own section in the tutorial
* remove mention of unrolling the loop
* Update Doc/tutorial/controlflow.rst
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
---------
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Closes#123242. The real criterion is that the attribute does not
exist on heap types, but I don't think we should discuss heap vs.
static types in the language reference.
* gh-124370: Add "howto" for free-threaded Python
This is a guide aimed at people writing Python code, as oppposed to the
existing guide for C API extension authors.
* Add missing new line
* Update Doc/howto/free-threading-python.rst
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
* interned -> immortalized
* Apply suggestions from code review
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
* Update Doc/howto/free-threading-python.rst
Co-authored-by: mpage <mpage@cs.stanford.edu>
* Update docs
* Apply suggestions from code review
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
* A few more updates
* Additional comment on immortal objects
* Mention specializing adaptive interpreter
* Remove trailing whitespace
* Remove mention of C macro
---------
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: mpage <mpage@cs.stanford.edu>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Make `versionchanged:: next`` expand to current (unreleased) version.
When a new CPython release is cut, the release manager will replace
all such occurences of "next" with the just-released version.
(See the issue for release-tools and devguide PRs.)
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Gregory P. Smith
Tian Gao
Wulian
Victorien
Adam Turner
Ned Deily
CBerJun
Serhiy Storchaka
Jelle Zijlstra
Jean-François B.
Raymond Hettinger
Pablo Galindo Salgado
Petr Viktorin
Matt Delengowski
Emily Morehouse
Victor Stinner
Alex Waygood
sobolevn
Max Bachmann
Ned Batchelder
Hugo van Kemenade
Matthew Rahtz
Tomas R
Sergey B Kirpichev
Ron Frederick
dgpb
Savannah Ostrowski
Nice Zombies
Sam Gross