They used to be shared, before 3.12. Returning to sharing them resolves a failure on Py_TRACE_REFS builds.
Co-authored-by: Petr Viktorin <encukou@gmail.com>
This is a follow up of GH-124974. Only Glibc needed a fix.
Now the returned value is a string consisting of semicolon-separated
symbols on all Posix platforms.
Previously, copying a super object returned a copy of the instance
invoking super(). Pickling a super object could pickle the instance
invoking super() or fail, depending on its type and protocol.
Now deep copying returns a new super object and pickling pickles the super
object. Shallow copying returns the same super object.
This is an implementation of InterpreterPoolExecutor that builds on ThreadPoolExecutor.
(Note that this is not tied to PEP 734, which is strictly about adding a new stdlib module.)
Possible future improvements:
* support passing a script for the initializer or to submit()
* support passing (most) arbitrary functions without pickling
* support passing closures
* optionally exec functions against __main__ instead of the their original module
It is an alternate constructor which only accepts a single numeric argument.
Unlike to Decimal.from_float() it accepts also Decimal.
Unlike to the standard constructor, it does not accept strings and tuples.
It is an alternative constructor which only accepts a single numeric argument.
Unlike to Fraction.from_float() and Fraction.from_decimal() it accepts any
real numbers supported by the standard constructor (int, float, Decimal,
Rational numbers, objects with as_integer_ratio()).
Unlike to the standard constructor, it does not accept strings.
* Update sample code in asyncio-task.rst
This will change **coroutines** sample code in the **Awaitables** section and make the example clearer.
* Update Doc/library/asyncio-task.rst
Revert the added print
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
* Update Doc/library/asyncio-task.rst
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
---------
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
This follows GNU gzip, which defaults to using 0 as the mtime
for compressing stdin, where no file mtime is involved.
This makes the output of gzip.compress() deterministic by default,
greatly helping reproducible builds.
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Also improve the documentation. Specify how dest and metavar are derived
from add_argument() positional arguments.
Co-authored-by: Simon Law <sfllaw@sfllaw.ca>
* Add definitions for "context", "current context", and "context
management protocol".
* Update related definitions to be consistent with the new
definitions.
* Restructure the documentation for the `contextvars.Context` class
to prepare for adding context manager support, and for consistency
with the definitions.
* Use `testcode` and `testoutput` to test the `Context.run` example.
* Expand the documentation for the `Py_CONTEXT_EVENT_ENTER` and
`Py_CONTEXT_EVENT_EXIT` events to clarify and to prepare for
planned changes.
* Update `__future__.rst`
Fixed typo in the sentence :pep:`649`: *Deferred evaluation of annotations using descriptors* - James McCarthy
* Update `__future__.rst`
Fixed sphinx formatting
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Barry Warsaw <barry@python.org>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
The function now sets temporarily the LC_CTYPE locale to the locale
of the category that determines the requested value if the locales are
different and the resulting string is non-ASCII.
This temporary change affects other threads.
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".
---------
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>