Skip to content

Commit 133f94e

Browse files
committed
Merge branch 'main'
2 parents e0c2c1e + f21ed37 commit 133f94e

File tree

57 files changed

+6040
-232
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

57 files changed

+6040
-232
lines changed

Doc/c-api/datetime.rst

Lines changed: 46 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,11 +8,42 @@ DateTime Objects
88
Various date and time objects are supplied by the :mod:`datetime` module.
99
Before using any of these functions, the header file :file:`datetime.h` must be
1010
included in your source (note that this is not included by :file:`Python.h`),
11-
and the macro :c:macro:`!PyDateTime_IMPORT` must be invoked, usually as part of
11+
and the macro :c:macro:`PyDateTime_IMPORT` must be invoked, usually as part of
1212
the module initialisation function. The macro puts a pointer to a C structure
13-
into a static variable, :c:data:`!PyDateTimeAPI`, that is used by the following
13+
into a static variable, :c:data:`PyDateTimeAPI`, that is used by the following
1414
macros.
1515

16+
.. c:macro:: PyDateTime_IMPORT()
17+
18+
Import the datetime C API.
19+
20+
On success, populate the :c:var:`PyDateTimeAPI` pointer.
21+
On failure, set :c:var:`PyDateTimeAPI` to ``NULL`` and set an exception.
22+
The caller must check if an error occurred via :c:func:`PyErr_Occurred`:
23+
24+
.. code-block::
25+
26+
PyDateTime_IMPORT;
27+
if (PyErr_Occurred()) { /* cleanup */ }
28+
29+
.. warning::
30+
31+
This is not compatible with subinterpreters.
32+
33+
.. c:type:: PyDateTime_CAPI
34+
35+
Structure containing the fields for the datetime C API.
36+
37+
The fields of this structure are private and subject to change.
38+
39+
Do not use this directly; prefer ``PyDateTime_*`` APIs instead.
40+
41+
.. c:var:: PyDateTime_CAPI *PyDateTimeAPI
42+
43+
Dynamically allocated object containing the datetime C API.
44+
45+
This variable is only available once :c:macro:`PyDateTime_IMPORT` succeeds.
46+
1647
.. c:type:: PyDateTime_Date
1748
1849
This subtype of :c:type:`PyObject` represents a Python date object.
@@ -325,3 +356,16 @@ Macros for the convenience of modules implementing the DB API:
325356
326357
Create and return a new :class:`datetime.date` object given an argument
327358
tuple suitable for passing to :meth:`datetime.date.fromtimestamp`.
359+
360+
361+
Internal data
362+
-------------
363+
364+
The following symbols are exposed by the C API but should be considered
365+
internal-only.
366+
367+
.. c:macro:: PyDateTime_CAPSULE_NAME
368+
369+
Name of the datetime capsule to pass to :c:func:`PyCapsule_Import`.
370+
371+
Internal usage only. Use :c:macro:`PyDateTime_IMPORT` instead.

Doc/c-api/gen.rst

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -44,3 +44,41 @@ than explicitly calling :c:func:`PyGen_New` or :c:func:`PyGen_NewWithQualName`.
4444
with ``__name__`` and ``__qualname__`` set to *name* and *qualname*.
4545
A reference to *frame* is stolen by this function. The *frame* argument
4646
must not be ``NULL``.
47+
48+
.. c:function:: PyCodeObject* PyGen_GetCode(PyGenObject *gen)
49+
50+
Return a new :term:`strong reference` to the code object wrapped by *gen*.
51+
This function always succeeds.
52+
53+
54+
Asynchronous Generator Objects
55+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
56+
57+
.. seealso::
58+
:pep:`525`
59+
60+
.. c:var:: PyTypeObject PyAsyncGen_Type
61+
62+
The type object corresponding to asynchronous generator objects. This is
63+
available as :class:`types.AsyncGeneratorType` in the Python layer.
64+
65+
.. versionadded:: 3.6
66+
67+
.. c:function:: PyObject *PyAsyncGen_New(PyFrameObject *frame, PyObject *name, PyObject *qualname)
68+
69+
Create a new asynchronous generator wrapping *frame*, with ``__name__`` and
70+
``__qualname__`` set to *name* and *qualname*. *frame* is stolen by this
71+
function and must not be ``NULL``.
72+
73+
On success, this function returns a :term:`strong reference` to the
74+
new asynchronous generator. On failure, this function returns ``NULL``
75+
with an exception set.
76+
77+
.. versionadded:: 3.6
78+
79+
.. c:function:: int PyAsyncGen_CheckExact(PyObject *op)
80+
81+
Return true if *op* is an asynchronous generator object, false otherwise.
82+
This function always succeeds.
83+
84+
.. versionadded:: 3.6

Doc/c-api/init.rst

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1891,6 +1891,25 @@ pointer and a void pointer argument.
18911891
This function now always schedules *func* to be run in the main
18921892
interpreter.
18931893
1894+
1895+
.. c:function:: int Py_MakePendingCalls(void)
1896+
1897+
Execute all pending calls. This is usually executed automatically by the
1898+
interpreter.
1899+
1900+
This function returns ``0`` on success, and returns ``-1`` with an exception
1901+
set on failure.
1902+
1903+
If this is not called in the main thread of the main
1904+
interpreter, this function does nothing and returns ``0``.
1905+
The caller must hold an :term:`attached thread state`.
1906+
1907+
.. versionadded:: 3.1
1908+
1909+
.. versionchanged:: 3.12
1910+
This function only runs pending calls in the main interpreter.
1911+
1912+
18941913
.. _profiling:
18951914
18961915
Profiling and Tracing

Doc/c-api/type.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -638,7 +638,7 @@ The following functions and structs are used to create
638638
under the :ref:`limited API <limited-c-api>`.
639639
640640
.. versionchanged:: 3.14
641-
The field :c:member:`~PyTypeObject.tp_vectorcall` can now set
641+
The field :c:member:`~PyTypeObject.tp_vectorcall` can now be set
642642
using :c:data:`Py_tp_vectorcall`. See the field's documentation
643643
for details.
644644

Doc/library/argparse.rst

Lines changed: 14 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1322,20 +1322,25 @@ attribute is determined by the ``dest`` keyword argument of
13221322

13231323
For optional argument actions, the value of ``dest`` is normally inferred from
13241324
the option strings. :class:`ArgumentParser` generates the value of ``dest`` by
1325-
taking the first long option string and stripping away the initial ``--``
1326-
string. If no long option strings were supplied, ``dest`` will be derived from
1325+
taking the first double-dash long option string and stripping away the initial
1326+
``-`` characters.
1327+
If no double-dash long option strings were supplied, ``dest`` will be derived
1328+
from the first single-dash long option string by stripping the initial ``-``
1329+
character.
1330+
If no long option strings were supplied, ``dest`` will be derived from
13271331
the first short option string by stripping the initial ``-`` character. Any
13281332
internal ``-`` characters will be converted to ``_`` characters to make sure
13291333
the string is a valid attribute name. The examples below illustrate this
13301334
behavior::
13311335

13321336
>>> parser = argparse.ArgumentParser()
13331337
>>> parser.add_argument('-f', '--foo-bar', '--foo')
1338+
>>> parser.add_argument('-q', '-quz')
13341339
>>> parser.add_argument('-x', '-y')
1335-
>>> parser.parse_args('-f 1 -x 2'.split())
1336-
Namespace(foo_bar='1', x='2')
1337-
>>> parser.parse_args('--foo 1 -y 2'.split())
1338-
Namespace(foo_bar='1', x='2')
1340+
>>> parser.parse_args('-f 1 -q 2 -x 3'.split())
1341+
Namespace(foo_bar='1', quz='2', x='3')
1342+
>>> parser.parse_args('--foo 1 -quz 2 -y 3'.split())
1343+
Namespace(foo_bar='1', quz='2', x='2')
13391344

13401345
``dest`` allows a custom attribute name to be provided::
13411346

@@ -1344,6 +1349,9 @@ behavior::
13441349
>>> parser.parse_args('--foo XXX'.split())
13451350
Namespace(bar='XXX')
13461351

1352+
.. versionchanged:: next
1353+
Single-dash long option now takes precedence over short options.
1354+
13471355

13481356
.. _deprecated:
13491357

Doc/library/socket.rst

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -482,6 +482,9 @@ The AF_* and SOCK_* constants are now :class:`AddressFamily` and
482482
.. versionchanged:: 3.14
483483
Added support for ``TCP_QUICKACK`` on Windows platforms when available.
484484

485+
.. versionchanged:: next
486+
``IPV6_HDRINCL`` was added.
487+
485488

486489
.. data:: AF_CAN
487490
PF_CAN

Doc/whatsnew/3.15.rst

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1275,3 +1275,10 @@ that may require changes to your code.
12751275
Use its :meth:`!close` method or the :func:`contextlib.closing` context
12761276
manager to close it.
12771277
(Contributed by Osama Abdelkader and Serhiy Storchaka in :gh:`140601`.)
1278+
1279+
* If a short option and a single-dash long option are passed to
1280+
:meth:`argparse.ArgumentParser.add_argument`, *dest* is now inferred from
1281+
the single-dash long option. For example, in ``add_argument('-f', '-foo')``,
1282+
*dest* is now ``'foo'`` instead of ``'f'``.
1283+
Pass an explicit *dest* argument to preserve the old behavior.
1284+
(Contributed by Serhiy Storchaka in :gh:`138697`.)

Include/internal/pycore_backoff.h

Lines changed: 40 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -22,33 +22,48 @@ extern "C" {
2222
Another use is for the Tier 2 optimizer to decide when to create
2323
a new Tier 2 trace (executor). Again, exponential backoff is used.
2424
25-
The 16-bit counter is structured as a 12-bit unsigned 'value'
26-
and a 4-bit 'backoff' field. When resetting the counter, the
25+
The 16-bit counter is structured as a 13-bit unsigned 'value'
26+
and a 3-bit 'backoff' field. When resetting the counter, the
2727
backoff field is incremented (until it reaches a limit) and the
28-
value is set to a bit mask representing the value 2**backoff - 1.
29-
The maximum backoff is 12 (the number of bits in the value).
28+
value is set to a bit mask representing some prime value - 1.
29+
New values and backoffs for each backoff are calculated once
30+
at compile time and saved to value_and_backoff_next table.
31+
The maximum backoff is 6, since 7 is an UNREACHABLE_BACKOFF.
3032
3133
There is an exceptional value which must not be updated, 0xFFFF.
3234
*/
3335

34-
#define BACKOFF_BITS 4
35-
#define MAX_BACKOFF 12
36-
#define UNREACHABLE_BACKOFF 15
37-
38-
static inline bool
39-
is_unreachable_backoff_counter(_Py_BackoffCounter counter)
40-
{
41-
return counter.value_and_backoff == UNREACHABLE_BACKOFF;
42-
}
36+
#define BACKOFF_BITS 3
37+
#define BACKOFF_MASK 7
38+
#define MAX_BACKOFF 6
39+
#define UNREACHABLE_BACKOFF 7
40+
#define MAX_VALUE 0x1FFF
41+
42+
#define MAKE_VALUE_AND_BACKOFF(value, backoff) \
43+
((value << BACKOFF_BITS) | backoff)
44+
45+
// For previous backoff b we use value x such that
46+
// x + 1 is near to 2**(2*b+1) and x + 1 is prime.
47+
static const uint16_t value_and_backoff_next[] = {
48+
MAKE_VALUE_AND_BACKOFF(1, 1),
49+
MAKE_VALUE_AND_BACKOFF(6, 2),
50+
MAKE_VALUE_AND_BACKOFF(30, 3),
51+
MAKE_VALUE_AND_BACKOFF(126, 4),
52+
MAKE_VALUE_AND_BACKOFF(508, 5),
53+
MAKE_VALUE_AND_BACKOFF(2052, 6),
54+
// We use the same backoff counter for all backoffs >= MAX_BACKOFF.
55+
MAKE_VALUE_AND_BACKOFF(8190, 6),
56+
MAKE_VALUE_AND_BACKOFF(8190, 6),
57+
};
4358

4459
static inline _Py_BackoffCounter
4560
make_backoff_counter(uint16_t value, uint16_t backoff)
4661
{
47-
assert(backoff <= 15);
48-
assert(value <= 0xFFF);
49-
_Py_BackoffCounter result;
50-
result.value_and_backoff = (value << BACKOFF_BITS) | backoff;
51-
return result;
62+
assert(backoff <= UNREACHABLE_BACKOFF);
63+
assert(value <= MAX_VALUE);
64+
return ((_Py_BackoffCounter){
65+
.value_and_backoff = MAKE_VALUE_AND_BACKOFF(value, backoff)
66+
});
5267
}
5368

5469
static inline _Py_BackoffCounter
@@ -62,14 +77,11 @@ forge_backoff_counter(uint16_t counter)
6277
static inline _Py_BackoffCounter
6378
restart_backoff_counter(_Py_BackoffCounter counter)
6479
{
65-
assert(!is_unreachable_backoff_counter(counter));
66-
int backoff = counter.value_and_backoff & 15;
67-
if (backoff < MAX_BACKOFF) {
68-
return make_backoff_counter((1 << (backoff + 1)) - 1, backoff + 1);
69-
}
70-
else {
71-
return make_backoff_counter((1 << MAX_BACKOFF) - 1, MAX_BACKOFF);
72-
}
80+
uint16_t backoff = counter.value_and_backoff & BACKOFF_MASK;
81+
assert(backoff <= MAX_BACKOFF);
82+
return ((_Py_BackoffCounter){
83+
.value_and_backoff = value_and_backoff_next[backoff]
84+
});
7385
}
7486

7587
static inline _Py_BackoffCounter
@@ -113,7 +125,7 @@ trigger_backoff_counter(void)
113125
// as we always end up tracing the loop iteration's
114126
// exhaustion iteration. Which aborts our current tracer.
115127
#define JUMP_BACKWARD_INITIAL_VALUE 4000
116-
#define JUMP_BACKWARD_INITIAL_BACKOFF 12
128+
#define JUMP_BACKWARD_INITIAL_BACKOFF 6
117129
static inline _Py_BackoffCounter
118130
initial_jump_backoff_counter(void)
119131
{
@@ -126,7 +138,7 @@ initial_jump_backoff_counter(void)
126138
* otherwise when a side exit warms up we may construct
127139
* a new trace before the Tier 1 code has properly re-specialized. */
128140
#define SIDE_EXIT_INITIAL_VALUE 4000
129-
#define SIDE_EXIT_INITIAL_BACKOFF 12
141+
#define SIDE_EXIT_INITIAL_BACKOFF 6
130142

131143
static inline _Py_BackoffCounter
132144
initial_temperature_backoff_counter(void)

0 commit comments

Comments
 (0)