Python-checkins
Threads by month
- ----- 2024 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
January 2024
- 1 participants
- 801 discussions
![](https://secure.gravatar.com/avatar/cc7737cd64a84f1b5c61a160798e97ee.jpg?s=120&d=mm&r=g)
[3.12] gh-101100: Fix datetime reference warnings (GH-114661) (GH-114716)
by serhiy-storchaka 29 Jan '24
by serhiy-storchaka 29 Jan '24
29 Jan '24
https://github.com/python/cpython/commit/783339a086ebe5fc87b119a2348398f826…
commit: 783339a086ebe5fc87b119a2348398f826d1905c
branch: 3.12
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: serhiy-storchaka <storchaka(a)gmail.com>
date: 2024-01-29T17:12:03+02:00
summary:
[3.12] gh-101100: Fix datetime reference warnings (GH-114661) (GH-114716)
(cherry picked from commit e8b8f5e9c2da6a436360ce648061c90bdfcba863)
Co-authored-by: Skip Montanaro <skip.montanaro(a)gmail.com>
Co-authored-by: Serhiy Storchaka <storchaka(a)gmail.com>
files:
M Doc/conf.py
M Doc/library/datetime.rst
M Doc/tools/.nitignore
diff --git a/Doc/conf.py b/Doc/conf.py
index 862820637a8a5a..e05741479dbf34 100644
--- a/Doc/conf.py
+++ b/Doc/conf.py
@@ -83,20 +83,25 @@
nitpick_ignore = [
# Standard C functions
('c:func', 'calloc'),
+ ('c:func', 'ctime'),
('c:func', 'dlopen'),
('c:func', 'exec'),
('c:func', 'fcntl'),
('c:func', 'fork'),
('c:func', 'free'),
+ ('c:func', 'gettimeofday'),
('c:func', 'gmtime'),
+ ('c:func', 'localeconv'),
('c:func', 'localtime'),
('c:func', 'main'),
('c:func', 'malloc'),
+ ('c:func', 'mktime'),
('c:func', 'printf'),
('c:func', 'realloc'),
('c:func', 'snprintf'),
('c:func', 'sprintf'),
('c:func', 'stat'),
+ ('c:func', 'strftime'),
('c:func', 'system'),
('c:func', 'time'),
('c:func', 'vsnprintf'),
diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst
index c74417e36eb402..0abb0d6f108cbd 100644
--- a/Doc/library/datetime.rst
+++ b/Doc/library/datetime.rst
@@ -14,7 +14,7 @@
.. XXX what order should the types be discussed in?
-The :mod:`datetime` module supplies classes for manipulating dates and times.
+The :mod:`!datetime` module supplies classes for manipulating dates and times.
While date and time arithmetic is supported, the focus of the implementation is
on efficient attribute extraction for output formatting and manipulation.
@@ -70,7 +70,7 @@ These :class:`tzinfo` objects capture information about the offset from UTC
time, the time zone name, and whether daylight saving time is in effect.
Only one concrete :class:`tzinfo` class, the :class:`timezone` class, is
-supplied by the :mod:`datetime` module. The :class:`timezone` class can
+supplied by the :mod:`!datetime` module. The :class:`timezone` class can
represent simple timezones with fixed offsets from UTC, such as UTC itself or
North American EST and EDT timezones. Supporting timezones at deeper levels of
detail is up to the application. The rules for time adjustment across the
@@ -80,7 +80,7 @@ standard suitable for every application aside from UTC.
Constants
---------
-The :mod:`datetime` module exports the following constants:
+The :mod:`!datetime` module exports the following constants:
.. data:: MINYEAR
@@ -631,7 +631,7 @@ Notes:
date2.toordinal()``. Date comparison raises :exc:`TypeError` if
the other comparand isn't also a :class:`date` object. However,
``NotImplemented`` is returned instead if the other comparand has a
- :meth:`timetuple` attribute. This hook gives other kinds of date objects a
+ :attr:`~date.timetuple` attribute. This hook gives other kinds of date objects a
chance at implementing mixed-type comparison. If not, when a :class:`date`
object is compared to an object of a different type, :exc:`TypeError` is raised
unless the comparison is ``==`` or ``!=``. The latter cases return
@@ -1212,7 +1212,7 @@ Supported operations:
object addresses, datetime comparison normally raises :exc:`TypeError` if the
other comparand isn't also a :class:`.datetime` object. However,
``NotImplemented`` is returned instead if the other comparand has a
- :meth:`timetuple` attribute. This hook gives other kinds of date objects a
+ :attr:`~.datetime.timetuple` attribute. This hook gives other kinds of date objects a
chance at implementing mixed-type comparison. If not, when a :class:`.datetime`
object is compared to an object of a different type, :exc:`TypeError` is raised
unless the comparison is ``==`` or ``!=``. The latter cases return
@@ -1341,22 +1341,22 @@ Instance methods:
where ``yday = d.toordinal() - date(d.year, 1, 1).toordinal() + 1``
is the day number within the current year starting with ``1`` for January
- 1st. The :attr:`tm_isdst` flag of the result is set according to the
+ 1st. The :attr:`~time.struct_time.tm_isdst` flag of the result is set according to the
:meth:`dst` method: :attr:`.tzinfo` is ``None`` or :meth:`dst` returns
- ``None``, :attr:`tm_isdst` is set to ``-1``; else if :meth:`dst` returns a
- non-zero value, :attr:`tm_isdst` is set to ``1``; else :attr:`tm_isdst` is
+ ``None``, :attr:`!tm_isdst` is set to ``-1``; else if :meth:`dst` returns a
+ non-zero value, :attr:`!tm_isdst` is set to ``1``; else :attr:`!tm_isdst` is
set to ``0``.
.. method:: datetime.utctimetuple()
If :class:`.datetime` instance *d* is naive, this is the same as
- ``d.timetuple()`` except that :attr:`tm_isdst` is forced to 0 regardless of what
+ ``d.timetuple()`` except that :attr:`~.time.struct_time.tm_isdst` is forced to 0 regardless of what
``d.dst()`` returns. DST is never in effect for a UTC time.
If *d* is aware, *d* is normalized to UTC time, by subtracting
``d.utcoffset()``, and a :class:`time.struct_time` for the
- normalized time is returned. :attr:`tm_isdst` is forced to 0. Note
+ normalized time is returned. :attr:`!tm_isdst` is forced to 0. Note
that an :exc:`OverflowError` may be raised if *d*.year was
``MINYEAR`` or ``MAXYEAR`` and UTC adjustment spills over a year
boundary.
@@ -1544,7 +1544,7 @@ Instance methods:
Examples of Usage: :class:`.datetime`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Examples of working with :class:`~datetime.datetime` objects:
+Examples of working with :class:`.datetime` objects:
.. doctest::
@@ -1755,9 +1755,9 @@ is aware, :exc:`TypeError` is raised if an order comparison is attempted. For eq
comparisons, naive instances are never equal to aware instances.
If both comparands are aware, and have
-the same :attr:`~time.tzinfo` attribute, the common :attr:`~time.tzinfo` attribute is
+the same :attr:`~.time.tzinfo` attribute, the common :attr:`!tzinfo` attribute is
ignored and the base times are compared. If both comparands are aware and
-have different :attr:`~time.tzinfo` attributes, the comparands are first adjusted by
+have different :attr:`!tzinfo` attributes, the comparands are first adjusted by
subtracting their UTC offsets (obtained from ``self.utcoffset()``). In order
to stop mixed-type comparisons from falling back to the default comparison by
object address, when a :class:`.time` object is compared to an object of a
@@ -1765,7 +1765,7 @@ different type, :exc:`TypeError` is raised unless the comparison is ``==`` or
``!=``. The latter cases return :const:`False` or :const:`True`, respectively.
.. versionchanged:: 3.3
- Equality comparisons between aware and naive :class:`~datetime.time` instances
+ Equality comparisons between aware and naive :class:`.time` instances
don't raise :exc:`TypeError`.
In Boolean contexts, a :class:`.time` object is always considered to be true.
@@ -1972,7 +1972,7 @@ Examples of working with a :class:`.time` object::
You need to derive a concrete subclass, and (at least)
supply implementations of the standard :class:`tzinfo` methods needed by the
- :class:`.datetime` methods you use. The :mod:`datetime` module provides
+ :class:`.datetime` methods you use. The :mod:`!datetime` module provides
:class:`timezone`, a simple concrete subclass of :class:`tzinfo` which can
represent timezones with fixed offset from UTC such as UTC itself or North
American EST and EDT.
@@ -1985,7 +1985,7 @@ Examples of working with a :class:`.time` object::
A concrete subclass of :class:`tzinfo` may need to implement the following
methods. Exactly which methods are needed depends on the uses made of aware
- :mod:`datetime` objects. If in doubt, simply implement all of them.
+ :mod:`!datetime` objects. If in doubt, simply implement all of them.
.. method:: tzinfo.utcoffset(dt)
@@ -2026,7 +2026,7 @@ Examples of working with a :class:`.time` object::
already been added to the UTC offset returned by :meth:`utcoffset`, so there's
no need to consult :meth:`dst` unless you're interested in obtaining DST info
separately. For example, :meth:`datetime.timetuple` calls its :attr:`~.datetime.tzinfo`
- attribute's :meth:`dst` method to determine how the :attr:`tm_isdst` flag
+ attribute's :meth:`dst` method to determine how the :attr:`~time.struct_time.tm_isdst` flag
should be set, and :meth:`tzinfo.fromutc` calls :meth:`dst` to account for
DST changes when crossing time zones.
@@ -2042,7 +2042,7 @@ Examples of working with a :class:`.time` object::
relies on this, but cannot detect violations; it's the programmer's
responsibility to ensure it. If a :class:`tzinfo` subclass cannot guarantee
this, it may be able to override the default implementation of
- :meth:`tzinfo.fromutc` to work correctly with :meth:`astimezone` regardless.
+ :meth:`tzinfo.fromutc` to work correctly with :meth:`~.datetime.astimezone` regardless.
Most implementations of :meth:`dst` will probably look like one of these two::
@@ -2071,7 +2071,7 @@ Examples of working with a :class:`.time` object::
.. method:: tzinfo.tzname(dt)
Return the time zone name corresponding to the :class:`.datetime` object *dt*, as
- a string. Nothing about string names is defined by the :mod:`datetime` module,
+ a string. Nothing about string names is defined by the :mod:`!datetime` module,
and there's no requirement that it mean anything in particular. For example,
"GMT", "UTC", "-500", "-5:00", "EDT", "US/Eastern", "America/New York" are all
valid replies. Return ``None`` if a string name isn't known. Note that this is
@@ -2119,7 +2119,7 @@ There is one more :class:`tzinfo` method that a subclass may wish to override:
different years. An example of a time zone the default :meth:`fromutc`
implementation may not handle correctly in all cases is one where the standard
offset (from UTC) depends on the specific date and time passed, which can happen
- for political reasons. The default implementations of :meth:`astimezone` and
+ for political reasons. The default implementations of :meth:`~.datetime.astimezone` and
:meth:`fromutc` may not produce the result you want if the result is one of the
hours straddling the moment the standard offset changes.
@@ -2185,10 +2185,10 @@ hour that can't be spelled unambiguously in local wall time: the last hour of
daylight time. In Eastern, that's times of the form 5:MM UTC on the day
daylight time ends. The local wall clock leaps from 1:59 (daylight time) back
to 1:00 (standard time) again. Local times of the form 1:MM are ambiguous.
-:meth:`astimezone` mimics the local clock's behavior by mapping two adjacent UTC
+:meth:`~.datetime.astimezone` mimics the local clock's behavior by mapping two adjacent UTC
hours into the same local hour then. In the Eastern example, UTC times of the
form 5:MM and 6:MM both map to 1:MM when converted to Eastern, but earlier times
-have the :attr:`~datetime.fold` attribute set to 0 and the later times have it set to 1.
+have the :attr:`~.datetime.fold` attribute set to 0 and the later times have it set to 1.
For example, at the Fall back transition of 2016, we get::
>>> u0 = datetime(2016, 11, 6, 4, tzinfo=timezone.utc)
@@ -2203,10 +2203,10 @@ For example, at the Fall back transition of 2016, we get::
07:00:00 UTC = 02:00:00 EST 0
Note that the :class:`.datetime` instances that differ only by the value of the
-:attr:`~datetime.fold` attribute are considered equal in comparisons.
+:attr:`~.datetime.fold` attribute are considered equal in comparisons.
Applications that can't bear wall-time ambiguities should explicitly check the
-value of the :attr:`~datetime.fold` attribute or avoid using hybrid
+value of the :attr:`~.datetime.fold` attribute or avoid using hybrid
:class:`tzinfo` subclasses; there are no ambiguities when using :class:`timezone`,
or any other fixed-offset :class:`tzinfo` subclass (such as a class representing
only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).
@@ -2214,7 +2214,7 @@ only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).
.. seealso::
:mod:`zoneinfo`
- The :mod:`datetime` module has a basic :class:`timezone` class (for
+ The :mod:`!datetime` module has a basic :class:`timezone` class (for
handling arbitrary fixed offsets from UTC) and its :attr:`timezone.utc`
attribute (a UTC timezone instance).
@@ -2232,7 +2232,7 @@ only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).
.. _datetime-timezone:
:class:`timezone` Objects
---------------------------
+-------------------------
The :class:`timezone` class is a subclass of :class:`tzinfo`, each
instance of which represents a timezone defined by a fixed offset from
@@ -2307,8 +2307,8 @@ Class attributes:
.. _strftime-strptime-behavior:
-:meth:`strftime` and :meth:`strptime` Behavior
-----------------------------------------------
+:meth:`~.datetime.strftime` and :meth:`~.datetime.strptime` Behavior
+--------------------------------------------------------------------
:class:`date`, :class:`.datetime`, and :class:`.time` objects all support a
``strftime(format)`` method, to create a string representing the time under the
@@ -2318,8 +2318,8 @@ Conversely, the :meth:`datetime.strptime` class method creates a
:class:`.datetime` object from a string representing a date and time and a
corresponding format string.
-The table below provides a high-level comparison of :meth:`strftime`
-versus :meth:`strptime`:
+The table below provides a high-level comparison of :meth:`~.datetime.strftime`
+versus :meth:`~.datetime.strptime`:
+----------------+--------------------------------------------------------+------------------------------------------------------------------------------+
| | ``strftime`` | ``strptime`` |
@@ -2336,8 +2336,8 @@ versus :meth:`strptime`:
.. _format-codes:
-:meth:`strftime` and :meth:`strptime` Format Codes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:meth:`~.datetime.strftime` and :meth:`~.datetime.strptime` Format Codes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These methods accept format codes that can be used to parse and format dates::
@@ -2476,13 +2476,13 @@ convenience. These parameters all correspond to ISO 8601 date values.
| | naive). | -03:07:12.345216 | |
+-----------+--------------------------------+------------------------+-------+
-These may not be available on all platforms when used with the :meth:`strftime`
+These may not be available on all platforms when used with the :meth:`~.datetime.strftime`
method. The ISO 8601 year and ISO 8601 week directives are not interchangeable
-with the year and week number directives above. Calling :meth:`strptime` with
+with the year and week number directives above. Calling :meth:`~.datetime.strptime` with
incomplete or ambiguous ISO 8601 directives will raise a :exc:`ValueError`.
The full set of format codes supported varies across platforms, because Python
-calls the platform C library's :func:`strftime` function, and platform
+calls the platform C library's :c:func:`strftime` function, and platform
variations are common. To see the full set of format codes supported on your
platform, consult the :manpage:`strftime(3)` documentation. There are also
differences between platforms in handling of unsupported format specifiers.
@@ -2498,9 +2498,9 @@ Technical Detail
Broadly speaking, ``d.strftime(fmt)`` acts like the :mod:`time` module's
``time.strftime(fmt, d.timetuple())`` although not all objects support a
-:meth:`timetuple` method.
+:meth:`~date.timetuple` method.
-For the :meth:`datetime.strptime` class method, the default value is
+For the :meth:`.datetime.strptime` class method, the default value is
``1900-01-01T00:00:00.000``: any components not specified in the format string
will be pulled from the default value. [#]_
@@ -2535,27 +2535,27 @@ Notes:
contain non-ASCII characters.
(2)
- The :meth:`strptime` method can parse years in the full [1, 9999] range, but
+ The :meth:`~.datetime.strptime` method can parse years in the full [1, 9999] range, but
years < 1000 must be zero-filled to 4-digit width.
.. versionchanged:: 3.2
- In previous versions, :meth:`strftime` method was restricted to
+ In previous versions, :meth:`~.datetime.strftime` method was restricted to
years >= 1900.
.. versionchanged:: 3.3
- In version 3.2, :meth:`strftime` method was restricted to
+ In version 3.2, :meth:`~.datetime.strftime` method was restricted to
years >= 1000.
(3)
- When used with the :meth:`strptime` method, the ``%p`` directive only affects
+ When used with the :meth:`~.datetime.strptime` method, the ``%p`` directive only affects
the output hour field if the ``%I`` directive is used to parse the hour.
(4)
- Unlike the :mod:`time` module, the :mod:`datetime` module does not support
+ Unlike the :mod:`time` module, the :mod:`!datetime` module does not support
leap seconds.
(5)
- When used with the :meth:`strptime` method, the ``%f`` directive
+ When used with the :meth:`~.datetime.strptime` method, the ``%f`` directive
accepts from one to six digits and zero pads on the right. ``%f`` is
an extension to the set of format characters in the C standard (but
implemented separately in datetime objects, and therefore always
@@ -2568,7 +2568,7 @@ Notes:
For an aware object:
``%z``
- :meth:`utcoffset` is transformed into a string of the form
+ :meth:`~.datetime.utcoffset` is transformed into a string of the form
``±HHMM[SS[.ffffff]]``, where ``HH`` is a 2-digit string giving the number
of UTC offset hours, ``MM`` is a 2-digit string giving the number of UTC
offset minutes, ``SS`` is a 2-digit string giving the number of UTC offset
@@ -2576,14 +2576,14 @@ Notes:
offset microseconds. The ``ffffff`` part is omitted when the offset is a
whole number of seconds and both the ``ffffff`` and the ``SS`` part is
omitted when the offset is a whole number of minutes. For example, if
- :meth:`utcoffset` returns ``timedelta(hours=-3, minutes=-30)``, ``%z`` is
+ :meth:`~.datetime.utcoffset` returns ``timedelta(hours=-3, minutes=-30)``, ``%z`` is
replaced with the string ``'-0330'``.
.. versionchanged:: 3.7
The UTC offset is not restricted to a whole number of minutes.
.. versionchanged:: 3.7
- When the ``%z`` directive is provided to the :meth:`strptime` method,
+ When the ``%z`` directive is provided to the :meth:`~.datetime.strptime` method,
the UTC offsets can have a colon as a separator between hours, minutes
and seconds.
For example, ``'+01:00:00'`` will be parsed as an offset of one hour.
@@ -2594,11 +2594,11 @@ Notes:
hours, minutes and seconds.
``%Z``
- In :meth:`strftime`, ``%Z`` is replaced by an empty string if
- :meth:`tzname` returns ``None``; otherwise ``%Z`` is replaced by the
+ In :meth:`~.datetime.strftime`, ``%Z`` is replaced by an empty string if
+ :meth:`~.datetime.tzname` returns ``None``; otherwise ``%Z`` is replaced by the
returned value, which must be a string.
- :meth:`strptime` only accepts certain values for ``%Z``:
+ :meth:`~.datetime.strptime` only accepts certain values for ``%Z``:
1. any value in ``time.tzname`` for your machine's locale
2. the hard-coded values ``UTC`` and ``GMT``
@@ -2608,23 +2608,23 @@ Notes:
invalid values.
.. versionchanged:: 3.2
- When the ``%z`` directive is provided to the :meth:`strptime` method, an
+ When the ``%z`` directive is provided to the :meth:`~.datetime.strptime` method, an
aware :class:`.datetime` object will be produced. The ``tzinfo`` of the
result will be set to a :class:`timezone` instance.
(7)
- When used with the :meth:`strptime` method, ``%U`` and ``%W`` are only used
+ When used with the :meth:`~.datetime.strptime` method, ``%U`` and ``%W`` are only used
in calculations when the day of the week and the calendar year (``%Y``)
are specified.
(8)
Similar to ``%U`` and ``%W``, ``%V`` is only used in calculations when the
day of the week and the ISO year (``%G``) are specified in a
- :meth:`strptime` format string. Also note that ``%G`` and ``%Y`` are not
+ :meth:`~.datetime.strptime` format string. Also note that ``%G`` and ``%Y`` are not
interchangeable.
(9)
- When used with the :meth:`strptime` method, the leading zero is optional
+ When used with the :meth:`~.datetime.strptime` method, the leading zero is optional
for formats ``%d``, ``%m``, ``%H``, ``%I``, ``%M``, ``%S``, ``%j``, ``%U``,
``%W``, and ``%V``. Format ``%y`` does require a leading zero.
diff --git a/Doc/tools/.nitignore b/Doc/tools/.nitignore
index e520359e12ebe6..46a4f4e48e0e2a 100644
--- a/Doc/tools/.nitignore
+++ b/Doc/tools/.nitignore
@@ -35,7 +35,6 @@ Doc/library/chunk.rst
Doc/library/collections.rst
Doc/library/copy.rst
Doc/library/csv.rst
-Doc/library/datetime.rst
Doc/library/dbm.rst
Doc/library/decimal.rst
Doc/library/email.charset.rst
1
0
![](https://secure.gravatar.com/avatar/cc7737cd64a84f1b5c61a160798e97ee.jpg?s=120&d=mm&r=g)
29 Jan '24
https://github.com/python/cpython/commit/c87233fd3fa77067013c35328f8c4884f0…
commit: c87233fd3fa77067013c35328f8c4884f0567a59
branch: main
author: mpage <mpage(a)meta.com>
committer: erlend-aasland <erlend.aasland(a)protonmail.com>
date: 2024-01-29T15:08:23Z
summary:
gh-112050: Adapt collections.deque to Argument Clinic (#113963)
files:
A Misc/NEWS.d/next/Core and Builtins/2024-01-11-22-58-45.gh-issue-112050.hDuvDW.rst
M Include/internal/pycore_global_objects_fini_generated.h
M Include/internal/pycore_global_strings.h
M Include/internal/pycore_runtime_init_generated.h
M Include/internal/pycore_unicodeobject_generated.h
M Modules/_collectionsmodule.c
M Modules/clinic/_collectionsmodule.c.h
diff --git a/Include/internal/pycore_global_objects_fini_generated.h b/Include/internal/pycore_global_objects_fini_generated.h
index e92707051c12b7..57505b5388fd6c 100644
--- a/Include/internal/pycore_global_objects_fini_generated.h
+++ b/Include/internal/pycore_global_objects_fini_generated.h
@@ -1049,6 +1049,7 @@ _PyStaticObjects_CheckRefcnt(PyInterpreterState *interp) {
_PyStaticObject_CheckRefcnt((PyObject *)&_Py_ID(max_length));
_PyStaticObject_CheckRefcnt((PyObject *)&_Py_ID(maxdigits));
_PyStaticObject_CheckRefcnt((PyObject *)&_Py_ID(maxevents));
+ _PyStaticObject_CheckRefcnt((PyObject *)&_Py_ID(maxlen));
_PyStaticObject_CheckRefcnt((PyObject *)&_Py_ID(maxmem));
_PyStaticObject_CheckRefcnt((PyObject *)&_Py_ID(maxsplit));
_PyStaticObject_CheckRefcnt((PyObject *)&_Py_ID(maxvalue));
diff --git a/Include/internal/pycore_global_strings.h b/Include/internal/pycore_global_strings.h
index eb60b80c964d42..0f4f3b61910241 100644
--- a/Include/internal/pycore_global_strings.h
+++ b/Include/internal/pycore_global_strings.h
@@ -538,6 +538,7 @@ struct _Py_global_strings {
STRUCT_FOR_ID(max_length)
STRUCT_FOR_ID(maxdigits)
STRUCT_FOR_ID(maxevents)
+ STRUCT_FOR_ID(maxlen)
STRUCT_FOR_ID(maxmem)
STRUCT_FOR_ID(maxsplit)
STRUCT_FOR_ID(maxvalue)
diff --git a/Include/internal/pycore_runtime_init_generated.h b/Include/internal/pycore_runtime_init_generated.h
index 9b39de1d69c6c7..63a2b54c839a4b 100644
--- a/Include/internal/pycore_runtime_init_generated.h
+++ b/Include/internal/pycore_runtime_init_generated.h
@@ -1047,6 +1047,7 @@ extern "C" {
INIT_ID(max_length), \
INIT_ID(maxdigits), \
INIT_ID(maxevents), \
+ INIT_ID(maxlen), \
INIT_ID(maxmem), \
INIT_ID(maxsplit), \
INIT_ID(maxvalue), \
diff --git a/Include/internal/pycore_unicodeobject_generated.h b/Include/internal/pycore_unicodeobject_generated.h
index 898d386f4cfd05..bf8cdd85e4be5c 100644
--- a/Include/internal/pycore_unicodeobject_generated.h
+++ b/Include/internal/pycore_unicodeobject_generated.h
@@ -1455,6 +1455,9 @@ _PyUnicode_InitStaticStrings(PyInterpreterState *interp) {
string = &_Py_ID(maxevents);
assert(_PyUnicode_CheckConsistency(string, 1));
_PyUnicode_InternInPlace(interp, &string);
+ string = &_Py_ID(maxlen);
+ assert(_PyUnicode_CheckConsistency(string, 1));
+ _PyUnicode_InternInPlace(interp, &string);
string = &_Py_ID(maxmem);
assert(_PyUnicode_CheckConsistency(string, 1));
_PyUnicode_InternInPlace(interp, &string);
diff --git a/Misc/NEWS.d/next/Core and Builtins/2024-01-11-22-58-45.gh-issue-112050.hDuvDW.rst b/Misc/NEWS.d/next/Core and Builtins/2024-01-11-22-58-45.gh-issue-112050.hDuvDW.rst
new file mode 100644
index 00000000000000..e5f3d5ea0cea25
--- /dev/null
+++ b/Misc/NEWS.d/next/Core and Builtins/2024-01-11-22-58-45.gh-issue-112050.hDuvDW.rst
@@ -0,0 +1 @@
+Convert :class:`collections.deque` to use Argument Clinic.
diff --git a/Modules/_collectionsmodule.c b/Modules/_collectionsmodule.c
index c8cd53de5e2262..ef77d34b10e47b 100644
--- a/Modules/_collectionsmodule.c
+++ b/Modules/_collectionsmodule.c
@@ -44,8 +44,11 @@ find_module_state_by_def(PyTypeObject *type)
/*[clinic input]
module _collections
class _tuplegetter "_tuplegetterobject *" "clinic_state()->tuplegetter_type"
+class _collections.deque "dequeobject *" "clinic_state()->deque_type"
[clinic start generated code]*/
-/*[clinic end generated code: output=da39a3ee5e6b4b0d input=7356042a89862e0e]*/
+/*[clinic end generated code: output=da39a3ee5e6b4b0d input=a033cc2a8476b3f1]*/
+
+typedef struct dequeobject dequeobject;
/* We can safely assume type to be the defining class,
* since tuplegetter is not a base type */
@@ -53,6 +56,12 @@ class _tuplegetter "_tuplegetterobject *" "clinic_state()->tuplegetter_type"
#include "clinic/_collectionsmodule.c.h"
#undef clinic_state
+/*[python input]
+class dequeobject_converter(self_converter):
+ type = "dequeobject *"
+[python start generated code]*/
+/*[python end generated code: output=da39a3ee5e6b4b0d input=b6ae4a3ff852be2f]*/
+
/* collections module implementation of a deque() datatype
Written and maintained by Raymond D. Hettinger <python(a)rcn.com>
*/
@@ -121,7 +130,7 @@ typedef struct BLOCK {
struct BLOCK *rightlink;
} block;
-typedef struct {
+struct dequeobject {
PyObject_VAR_HEAD
block *leftblock;
block *rightblock;
@@ -132,7 +141,7 @@ typedef struct {
Py_ssize_t numfreeblocks;
block *freeblocks[MAXFREEBLOCKS];
PyObject *weakreflist;
-} dequeobject;
+};
/* For debug builds, add error checking to track the endpoints
* in the chain of links. The goal is to make sure that link
@@ -219,8 +228,17 @@ deque_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
return (PyObject *)deque;
}
+/*[clinic input]
+_collections.deque.pop as deque_pop
+
+ deque: dequeobject
+
+Remove and return the rightmost element.
+[clinic start generated code]*/
+
static PyObject *
-deque_pop(dequeobject *deque, PyObject *unused)
+deque_pop_impl(dequeobject *deque)
+/*[clinic end generated code: output=2e5f7890c4251f07 input=eb6e6d020f877dec]*/
{
PyObject *item;
block *prevblock;
@@ -254,10 +272,17 @@ deque_pop(dequeobject *deque, PyObject *unused)
return item;
}
-PyDoc_STRVAR(pop_doc, "Remove and return the rightmost element.");
+/*[clinic input]
+_collections.deque.popleft as deque_popleft
+
+ deque: dequeobject
+
+Remove and return the leftmost element.
+[clinic start generated code]*/
static PyObject *
-deque_popleft(dequeobject *deque, PyObject *unused)
+deque_popleft_impl(dequeobject *deque)
+/*[clinic end generated code: output=62b154897097ff68 input=acb41b9af50a9d9b]*/
{
PyObject *item;
block *prevblock;
@@ -292,8 +317,6 @@ deque_popleft(dequeobject *deque, PyObject *unused)
return item;
}
-PyDoc_STRVAR(popleft_doc, "Remove and return the leftmost element.");
-
/* The deque's size limit is d.maxlen. The limit can be zero or positive.
* If there is no limit, then d.maxlen == -1.
*
@@ -326,7 +349,7 @@ deque_append_internal(dequeobject *deque, PyObject *item, Py_ssize_t maxlen)
deque->rightindex++;
deque->rightblock->data[deque->rightindex] = item;
if (NEEDS_TRIM(deque, maxlen)) {
- PyObject *olditem = deque_popleft(deque, NULL);
+ PyObject *olditem = deque_popleft_impl(deque);
Py_DECREF(olditem);
} else {
deque->state++;
@@ -334,16 +357,25 @@ deque_append_internal(dequeobject *deque, PyObject *item, Py_ssize_t maxlen)
return 0;
}
+/*[clinic input]
+_collections.deque.append as deque_append
+
+ deque: dequeobject
+ item: object
+ /
+
+Add an element to the right side of the deque.
+[clinic start generated code]*/
+
static PyObject *
deque_append(dequeobject *deque, PyObject *item)
+/*[clinic end generated code: output=507b13efc4853ecc input=f112b83c380528e3]*/
{
if (deque_append_internal(deque, Py_NewRef(item), deque->maxlen) < 0)
return NULL;
Py_RETURN_NONE;
}
-PyDoc_STRVAR(append_doc, "Add an element to the right side of the deque.");
-
static inline int
deque_appendleft_internal(dequeobject *deque, PyObject *item, Py_ssize_t maxlen)
{
@@ -362,7 +394,7 @@ deque_appendleft_internal(dequeobject *deque, PyObject *item, Py_ssize_t maxlen)
deque->leftindex--;
deque->leftblock->data[deque->leftindex] = item;
if (NEEDS_TRIM(deque, deque->maxlen)) {
- PyObject *olditem = deque_pop(deque, NULL);
+ PyObject *olditem = deque_pop_impl(deque);
Py_DECREF(olditem);
} else {
deque->state++;
@@ -370,16 +402,25 @@ deque_appendleft_internal(dequeobject *deque, PyObject *item, Py_ssize_t maxlen)
return 0;
}
+/*[clinic input]
+_collections.deque.appendleft as deque_appendleft
+
+ deque: dequeobject
+ item: object
+ /
+
+Add an element to the left side of the deque.
+[clinic start generated code]*/
+
static PyObject *
deque_appendleft(dequeobject *deque, PyObject *item)
+/*[clinic end generated code: output=de0335a64800ffd8 input=bbdaa60a3e956062]*/
{
if (deque_appendleft_internal(deque, Py_NewRef(item), deque->maxlen) < 0)
return NULL;
Py_RETURN_NONE;
}
-PyDoc_STRVAR(appendleft_doc, "Add an element to the left side of the deque.");
-
static PyObject*
finalize_iterator(PyObject *it)
{
@@ -410,8 +451,19 @@ consume_iterator(PyObject *it)
return finalize_iterator(it);
}
+/*[clinic input]
+_collections.deque.extend as deque_extend
+
+ deque: dequeobject
+ iterable: object
+ /
+
+Extend the right side of the deque with elements from the iterable.
+[clinic start generated code]*/
+
static PyObject *
deque_extend(dequeobject *deque, PyObject *iterable)
+/*[clinic end generated code: output=a3a6e74d17063f8d input=cfebfd34d5383339]*/
{
PyObject *it, *item;
PyObject *(*iternext)(PyObject *);
@@ -454,11 +506,19 @@ deque_extend(dequeobject *deque, PyObject *iterable)
return finalize_iterator(it);
}
-PyDoc_STRVAR(extend_doc,
-"Extend the right side of the deque with elements from the iterable");
+/*[clinic input]
+_collections.deque.extendleft as deque_extendleft
+
+ deque: dequeobject
+ iterable: object
+ /
+
+Extend the left side of the deque with elements from the iterable.
+[clinic start generated code]*/
static PyObject *
deque_extendleft(dequeobject *deque, PyObject *iterable)
+/*[clinic end generated code: output=2dba946c50498c67 input=f4820e695a6f9416]*/
{
PyObject *it, *item;
PyObject *(*iternext)(PyObject *);
@@ -501,9 +561,6 @@ deque_extendleft(dequeobject *deque, PyObject *iterable)
return finalize_iterator(it);
}
-PyDoc_STRVAR(extendleft_doc,
-"Extend the left side of the deque with elements from the iterable");
-
static PyObject *
deque_inplace_concat(dequeobject *deque, PyObject *other)
{
@@ -517,8 +574,17 @@ deque_inplace_concat(dequeobject *deque, PyObject *other)
return (PyObject *)deque;
}
+/*[clinic input]
+_collections.deque.copy as deque_copy
+
+ deque: dequeobject
+
+Return a shallow copy of a deque.
+[clinic start generated code]*/
+
static PyObject *
-deque_copy(PyObject *deque, PyObject *Py_UNUSED(ignored))
+deque_copy_impl(dequeobject *deque)
+/*[clinic end generated code: output=6409b3d1ad2898b5 input=0e22f138bc1fcbee]*/
{
PyObject *result;
dequeobject *old_deque = (dequeobject *)deque;
@@ -537,7 +603,7 @@ deque_copy(PyObject *deque, PyObject *Py_UNUSED(ignored))
PyObject *item = old_deque->leftblock->data[old_deque->leftindex];
rv = deque_append(new_deque, item);
} else {
- rv = deque_extend(new_deque, deque);
+ rv = deque_extend(new_deque, (PyObject *)deque);
}
if (rv != NULL) {
Py_DECREF(rv);
@@ -547,7 +613,8 @@ deque_copy(PyObject *deque, PyObject *Py_UNUSED(ignored))
return NULL;
}
if (old_deque->maxlen < 0)
- result = PyObject_CallOneArg((PyObject *)(Py_TYPE(deque)), deque);
+ result = PyObject_CallOneArg((PyObject *)(Py_TYPE(deque)),
+ (PyObject *)deque);
else
result = PyObject_CallFunction((PyObject *)(Py_TYPE(deque)), "Oi",
deque, old_deque->maxlen, NULL);
@@ -561,7 +628,18 @@ deque_copy(PyObject *deque, PyObject *Py_UNUSED(ignored))
return result;
}
-PyDoc_STRVAR(copy_doc, "Return a shallow copy of a deque.");
+/*[clinic input]
+_collections.deque.__copy__ as deque___copy__ = _collections.deque.copy
+
+Return a shallow copy of a deque.
+[clinic start generated code]*/
+
+static PyObject *
+deque___copy___impl(dequeobject *deque)
+/*[clinic end generated code: output=7c5821504342bf23 input=fce05df783e7912b]*/
+{
+ return deque_copy_impl(deque);
+}
static PyObject *
deque_concat(dequeobject *deque, PyObject *other)
@@ -580,7 +658,7 @@ deque_concat(dequeobject *deque, PyObject *other)
return NULL;
}
- new_deque = deque_copy((PyObject *)deque, NULL);
+ new_deque = deque_copy_impl(deque);
if (new_deque == NULL)
return NULL;
result = deque_extend((dequeobject *)new_deque, other);
@@ -669,22 +747,29 @@ deque_clear(dequeobject *deque)
alternate_method:
while (Py_SIZE(deque)) {
- item = deque_pop(deque, NULL);
+ item = deque_pop_impl(deque);
assert (item != NULL);
Py_DECREF(item);
}
return 0;
}
+/*[clinic input]
+_collections.deque.clear as deque_clearmethod
+
+ deque: dequeobject
+
+Remove all elements from the deque.
+[clinic start generated code]*/
+
static PyObject *
-deque_clearmethod(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+deque_clearmethod_impl(dequeobject *deque)
+/*[clinic end generated code: output=79b2513e097615c1 input=20488eb932f89f9e]*/
{
deque_clear(deque);
Py_RETURN_NONE;
}
-PyDoc_STRVAR(clear_doc, "Remove all elements from the deque.");
-
static PyObject *
deque_inplace_repeat(dequeobject *deque, Py_ssize_t n)
{
@@ -768,7 +853,7 @@ deque_repeat(dequeobject *deque, Py_ssize_t n)
dequeobject *new_deque;
PyObject *rv;
- new_deque = (dequeobject *)deque_copy((PyObject *) deque, NULL);
+ new_deque = (dequeobject *)deque_copy_impl(deque);
if (new_deque == NULL)
return NULL;
rv = deque_inplace_repeat(new_deque, n);
@@ -925,36 +1010,36 @@ _deque_rotate(dequeobject *deque, Py_ssize_t n)
return rv;
}
-static PyObject *
-deque_rotate(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
-{
- Py_ssize_t n=1;
+/*[clinic input]
+_collections.deque.rotate as deque_rotate
- if (!_PyArg_CheckPositional("deque.rotate", nargs, 0, 1)) {
- return NULL;
- }
- if (nargs) {
- PyObject *index = _PyNumber_Index(args[0]);
- if (index == NULL) {
- return NULL;
- }
- n = PyLong_AsSsize_t(index);
- Py_DECREF(index);
- if (n == -1 && PyErr_Occurred()) {
- return NULL;
- }
- }
+ deque: dequeobject
+ n: Py_ssize_t = 1
+ /
+Rotate the deque n steps to the right. If n is negative, rotates left.
+[clinic start generated code]*/
+
+static PyObject *
+deque_rotate_impl(dequeobject *deque, Py_ssize_t n)
+/*[clinic end generated code: output=96c2402a371eb15d input=d22070f49cc06c76]*/
+{
if (!_deque_rotate(deque, n))
Py_RETURN_NONE;
return NULL;
}
-PyDoc_STRVAR(rotate_doc,
-"Rotate the deque n steps to the right (default n=1). If n is negative, rotates left.");
+/*[clinic input]
+_collections.deque.reverse as deque_reverse
+
+ deque: dequeobject
+
+Reverse *IN PLACE*.
+[clinic start generated code]*/
static PyObject *
-deque_reverse(dequeobject *deque, PyObject *unused)
+deque_reverse_impl(dequeobject *deque)
+/*[clinic end generated code: output=bdeebc2cf8c1f064 input=f139787f406101c9]*/
{
block *leftblock = deque->leftblock;
block *rightblock = deque->rightblock;
@@ -991,11 +1076,19 @@ deque_reverse(dequeobject *deque, PyObject *unused)
Py_RETURN_NONE;
}
-PyDoc_STRVAR(reverse_doc,
-"D.reverse() -- reverse *IN PLACE*");
+/*[clinic input]
+_collections.deque.count as deque_count
+
+ deque: dequeobject
+ value as v: object
+ /
+
+Return number of occurrences of value.
+[clinic start generated code]*/
static PyObject *
deque_count(dequeobject *deque, PyObject *v)
+/*[clinic end generated code: output=7405d289d94d7b9b input=1892925260ff5d78]*/
{
block *b = deque->leftblock;
Py_ssize_t index = deque->leftindex;
@@ -1030,9 +1123,6 @@ deque_count(dequeobject *deque, PyObject *v)
return PyLong_FromSsize_t(count);
}
-PyDoc_STRVAR(count_doc,
-"D.count(value) -- return number of occurrences of value");
-
static int
deque_contains(dequeobject *deque, PyObject *v)
{
@@ -1071,22 +1161,33 @@ deque_len(dequeobject *deque)
return Py_SIZE(deque);
}
+/*[clinic input]
+@text_signature "($self, value, [start, [stop]])"
+_collections.deque.index as deque_index
+
+ deque: dequeobject
+ value as v: object
+ start: object(converter='_PyEval_SliceIndexNotNone', type='Py_ssize_t', c_default='0') = NULL
+ stop: object(converter='_PyEval_SliceIndexNotNone', type='Py_ssize_t', c_default='Py_SIZE(deque)') = NULL
+ /
+
+Return first index of value.
+
+Raises ValueError if the value is not present.
+[clinic start generated code]*/
+
static PyObject *
-deque_index(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
+deque_index_impl(dequeobject *deque, PyObject *v, Py_ssize_t start,
+ Py_ssize_t stop)
+/*[clinic end generated code: output=df45132753175ef9 input=140210c099830f64]*/
{
- Py_ssize_t i, n, start=0, stop=Py_SIZE(deque);
- PyObject *v, *item;
+ Py_ssize_t i, n;
+ PyObject *item;
block *b = deque->leftblock;
Py_ssize_t index = deque->leftindex;
size_t start_state = deque->state;
int cmp;
- if (!_PyArg_ParseStack(args, nargs, "O|O&O&:index", &v,
- _PyEval_SliceIndexNotNone, &start,
- _PyEval_SliceIndexNotNone, &stop)) {
- return NULL;
- }
-
if (start < 0) {
start += Py_SIZE(deque);
if (start < 0)
@@ -1138,10 +1239,6 @@ deque_index(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
return NULL;
}
-PyDoc_STRVAR(index_doc,
-"D.index(value, [start, [stop]]) -- return first index of value.\n"
-"Raises ValueError if the value is not present.");
-
/* insert(), remove(), and delitem() are implemented in terms of
rotate() for simplicity and reasonable performance near the end
points. If for some reason these methods become popular, it is not
@@ -1150,18 +1247,24 @@ PyDoc_STRVAR(index_doc,
boost (by moving each pointer only once instead of twice).
*/
+/*[clinic input]
+_collections.deque.insert as deque_insert
+
+ deque: dequeobject
+ index: Py_ssize_t
+ value: object
+ /
+
+Insert value before index.
+[clinic start generated code]*/
+
static PyObject *
-deque_insert(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
+deque_insert_impl(dequeobject *deque, Py_ssize_t index, PyObject *value)
+/*[clinic end generated code: output=ef4d2c15d5532b80 input=3e5c1c120d70c0e6]*/
{
- Py_ssize_t index;
Py_ssize_t n = Py_SIZE(deque);
- PyObject *value;
PyObject *rv;
- if (!_PyArg_ParseStack(args, nargs, "nO:insert", &index, &value)) {
- return NULL;
- }
-
if (deque->maxlen == Py_SIZE(deque)) {
PyErr_SetString(PyExc_IndexError, "deque already at its maximum size");
return NULL;
@@ -1184,12 +1287,6 @@ deque_insert(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
Py_RETURN_NONE;
}
-PyDoc_STRVAR(insert_doc,
-"D.insert(index, object) -- insert object before index");
-
-PyDoc_STRVAR(remove_doc,
-"D.remove(value) -- remove first occurrence of value.");
-
static int
valid_index(Py_ssize_t i, Py_ssize_t limit)
{
@@ -1246,15 +1343,26 @@ deque_del_item(dequeobject *deque, Py_ssize_t i)
assert (i >= 0 && i < Py_SIZE(deque));
if (_deque_rotate(deque, -i))
return -1;
- item = deque_popleft(deque, NULL);
+ item = deque_popleft_impl(deque);
rv = _deque_rotate(deque, i);
assert (item != NULL);
Py_DECREF(item);
return rv;
}
+/*[clinic input]
+_collections.deque.remove as deque_remove
+
+ deque: dequeobject
+ value: object
+ /
+
+Remove first occurrence of value.
+[clinic start generated code]*/
+
static PyObject *
deque_remove(dequeobject *deque, PyObject *value)
+/*[clinic end generated code: output=49e1666d612fe911 input=d972f32d15990880]*/
{
PyObject *item;
block *b = deque->leftblock;
@@ -1375,8 +1483,17 @@ deque_traverse(dequeobject *deque, visitproc visit, void *arg)
return 0;
}
+/*[clinic input]
+_collections.deque.__reduce__ as deque___reduce__
+
+ deque: dequeobject
+
+Return state information for pickling.
+[clinic start generated code]*/
+
static PyObject *
-deque_reduce(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+deque___reduce___impl(dequeobject *deque)
+/*[clinic end generated code: output=cb85d9e0b7d2c5ad input=991a933a5bc7a526]*/
{
PyObject *state, *it;
@@ -1510,26 +1627,23 @@ deque_richcompare(PyObject *v, PyObject *w, int op)
return NULL;
}
+/*[clinic input]
+@text_signature "([iterable[, maxlen]])"
+_collections.deque.__init__ as deque_init
+
+ deque: dequeobject
+ iterable: object = NULL
+ maxlen as maxlenobj: object = NULL
+
+A list-like sequence optimized for data accesses near its endpoints.
+[clinic start generated code]*/
+
static int
-deque_init(dequeobject *deque, PyObject *args, PyObject *kwdargs)
+deque_init_impl(dequeobject *deque, PyObject *iterable, PyObject *maxlenobj)
+/*[clinic end generated code: output=7084a39d71218dcd input=5ebdffc48a2d27ae]*/
+
{
- PyObject *iterable = NULL;
- PyObject *maxlenobj = NULL;
Py_ssize_t maxlen = -1;
- char *kwlist[] = {"iterable", "maxlen", 0};
-
- if (kwdargs == NULL && PyTuple_GET_SIZE(args) <= 2) {
- if (PyTuple_GET_SIZE(args) > 0) {
- iterable = PyTuple_GET_ITEM(args, 0);
- }
- if (PyTuple_GET_SIZE(args) > 1) {
- maxlenobj = PyTuple_GET_ITEM(args, 1);
- }
- } else {
- if (!PyArg_ParseTupleAndKeywords(args, kwdargs, "|OO:deque", kwlist,
- &iterable, &maxlenobj))
- return -1;
- }
if (maxlenobj != NULL && maxlenobj != Py_None) {
maxlen = PyLong_AsSsize_t(maxlenobj);
if (maxlen == -1 && PyErr_Occurred())
@@ -1551,8 +1665,17 @@ deque_init(dequeobject *deque, PyObject *args, PyObject *kwdargs)
return 0;
}
+/*[clinic input]
+_collections.deque.__sizeof__ as deque___sizeof__
+
+ deque: dequeobject
+
+Return the size of the deque in memory, in bytes.
+[clinic start generated code]*/
+
static PyObject *
-deque_sizeof(dequeobject *deque, void *unused)
+deque___sizeof___impl(dequeobject *deque)
+/*[clinic end generated code: output=4d36e9fb4f30bbaf input=4e7c9a00c03c3290]*/
{
size_t res = _PyObject_SIZE(Py_TYPE(deque));
size_t blocks;
@@ -1563,9 +1686,6 @@ deque_sizeof(dequeobject *deque, void *unused)
return PyLong_FromSize_t(res);
}
-PyDoc_STRVAR(sizeof_doc,
-"D.__sizeof__() -- size of D in memory, in bytes");
-
static PyObject *
deque_get_maxlen(dequeobject *deque, void *Py_UNUSED(ignored))
{
@@ -1574,6 +1694,22 @@ deque_get_maxlen(dequeobject *deque, void *Py_UNUSED(ignored))
return PyLong_FromSsize_t(deque->maxlen);
}
+static PyObject *deque_reviter(dequeobject *deque);
+
+/*[clinic input]
+_collections.deque.__reversed__ as deque___reversed__
+
+ deque: dequeobject
+
+Return a reverse iterator over the deque.
+[clinic start generated code]*/
+
+static PyObject *
+deque___reversed___impl(dequeobject *deque)
+/*[clinic end generated code: output=3e7e7e715883cf2e input=3d494c25a6fe5c7e]*/
+{
+ return deque_reviter(deque);
+}
/* deque object ********************************************************/
@@ -1584,47 +1720,26 @@ static PyGetSetDef deque_getset[] = {
};
static PyObject *deque_iter(dequeobject *deque);
-static PyObject *deque_reviter(dequeobject *deque, PyObject *Py_UNUSED(ignored));
-PyDoc_STRVAR(reversed_doc,
- "D.__reversed__() -- return a reverse iterator over the deque");
static PyMethodDef deque_methods[] = {
- {"append", (PyCFunction)deque_append,
- METH_O, append_doc},
- {"appendleft", (PyCFunction)deque_appendleft,
- METH_O, appendleft_doc},
- {"clear", (PyCFunction)deque_clearmethod,
- METH_NOARGS, clear_doc},
- {"__copy__", deque_copy,
- METH_NOARGS, copy_doc},
- {"copy", deque_copy,
- METH_NOARGS, copy_doc},
- {"count", (PyCFunction)deque_count,
- METH_O, count_doc},
- {"extend", (PyCFunction)deque_extend,
- METH_O, extend_doc},
- {"extendleft", (PyCFunction)deque_extendleft,
- METH_O, extendleft_doc},
- {"index", _PyCFunction_CAST(deque_index),
- METH_FASTCALL, index_doc},
- {"insert", _PyCFunction_CAST(deque_insert),
- METH_FASTCALL, insert_doc},
- {"pop", (PyCFunction)deque_pop,
- METH_NOARGS, pop_doc},
- {"popleft", (PyCFunction)deque_popleft,
- METH_NOARGS, popleft_doc},
- {"__reduce__", (PyCFunction)deque_reduce,
- METH_NOARGS, reduce_doc},
- {"remove", (PyCFunction)deque_remove,
- METH_O, remove_doc},
- {"__reversed__", (PyCFunction)deque_reviter,
- METH_NOARGS, reversed_doc},
- {"reverse", (PyCFunction)deque_reverse,
- METH_NOARGS, reverse_doc},
- {"rotate", _PyCFunction_CAST(deque_rotate),
- METH_FASTCALL, rotate_doc},
- {"__sizeof__", (PyCFunction)deque_sizeof,
- METH_NOARGS, sizeof_doc},
+ DEQUE_APPEND_METHODDEF
+ DEQUE_APPENDLEFT_METHODDEF
+ DEQUE_CLEARMETHOD_METHODDEF
+ DEQUE___COPY___METHODDEF
+ DEQUE_COPY_METHODDEF
+ DEQUE_COUNT_METHODDEF
+ DEQUE_EXTEND_METHODDEF
+ DEQUE_EXTENDLEFT_METHODDEF
+ DEQUE_INDEX_METHODDEF
+ DEQUE_INSERT_METHODDEF
+ DEQUE_POP_METHODDEF
+ DEQUE_POPLEFT_METHODDEF
+ DEQUE___REDUCE___METHODDEF
+ DEQUE_REMOVE_METHODDEF
+ DEQUE___REVERSED___METHODDEF
+ DEQUE_REVERSE_METHODDEF
+ DEQUE_ROTATE_METHODDEF
+ DEQUE___SIZEOF___METHODDEF
{"__class_getitem__", Py_GenericAlias,
METH_O|METH_CLASS, PyDoc_STR("See PEP 585")},
{NULL, NULL} /* sentinel */
@@ -1635,17 +1750,12 @@ static PyMemberDef deque_members[] = {
{NULL},
};
-PyDoc_STRVAR(deque_doc,
-"deque([iterable[, maxlen]]) --> deque object\n\
-\n\
-A list-like sequence optimized for data accesses near its endpoints.");
-
static PyType_Slot deque_slots[] = {
{Py_tp_dealloc, deque_dealloc},
{Py_tp_repr, deque_repr},
{Py_tp_hash, PyObject_HashNotImplemented},
{Py_tp_getattro, PyObject_GenericGetAttr},
- {Py_tp_doc, (void *)deque_doc},
+ {Py_tp_doc, (void *)deque_init__doc__},
{Py_tp_traverse, deque_traverse},
{Py_tp_clear, deque_clear},
{Py_tp_richcompare, deque_richcompare},
@@ -1834,7 +1944,7 @@ static PyType_Spec dequeiter_spec = {
/*********************** Deque Reverse Iterator **************************/
static PyObject *
-deque_reviter(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+deque_reviter(dequeobject *deque)
{
dequeiterobject *it;
collections_state *state = find_module_state_by_def(Py_TYPE(deque));
@@ -1889,7 +1999,7 @@ dequereviter_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
return NULL;
assert(type == state->dequereviter_type);
- it = (dequeiterobject*)deque_reviter((dequeobject *)deque, NULL);
+ it = (dequeiterobject *)deque_reviter((dequeobject *)deque);
if (!it)
return NULL;
/* consume items from the queue */
diff --git a/Modules/clinic/_collectionsmodule.c.h b/Modules/clinic/_collectionsmodule.c.h
index 591ab50c76a8e8..60fb12a2231619 100644
--- a/Modules/clinic/_collectionsmodule.c.h
+++ b/Modules/clinic/_collectionsmodule.c.h
@@ -2,9 +2,425 @@
preserve
[clinic start generated code]*/
+#if defined(Py_BUILD_CORE) && !defined(Py_BUILD_CORE_MODULE)
+# include "pycore_gc.h" // PyGC_Head
+# include "pycore_runtime.h" // _Py_ID()
+#endif
#include "pycore_abstract.h" // _PyNumber_Index()
#include "pycore_modsupport.h" // _PyArg_CheckPositional()
+PyDoc_STRVAR(deque_pop__doc__,
+"pop($self, /)\n"
+"--\n"
+"\n"
+"Remove and return the rightmost element.");
+
+#define DEQUE_POP_METHODDEF \
+ {"pop", (PyCFunction)deque_pop, METH_NOARGS, deque_pop__doc__},
+
+static PyObject *
+deque_pop_impl(dequeobject *deque);
+
+static PyObject *
+deque_pop(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque_pop_impl(deque);
+}
+
+PyDoc_STRVAR(deque_popleft__doc__,
+"popleft($self, /)\n"
+"--\n"
+"\n"
+"Remove and return the leftmost element.");
+
+#define DEQUE_POPLEFT_METHODDEF \
+ {"popleft", (PyCFunction)deque_popleft, METH_NOARGS, deque_popleft__doc__},
+
+static PyObject *
+deque_popleft_impl(dequeobject *deque);
+
+static PyObject *
+deque_popleft(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque_popleft_impl(deque);
+}
+
+PyDoc_STRVAR(deque_append__doc__,
+"append($self, item, /)\n"
+"--\n"
+"\n"
+"Add an element to the right side of the deque.");
+
+#define DEQUE_APPEND_METHODDEF \
+ {"append", (PyCFunction)deque_append, METH_O, deque_append__doc__},
+
+PyDoc_STRVAR(deque_appendleft__doc__,
+"appendleft($self, item, /)\n"
+"--\n"
+"\n"
+"Add an element to the left side of the deque.");
+
+#define DEQUE_APPENDLEFT_METHODDEF \
+ {"appendleft", (PyCFunction)deque_appendleft, METH_O, deque_appendleft__doc__},
+
+PyDoc_STRVAR(deque_extend__doc__,
+"extend($self, iterable, /)\n"
+"--\n"
+"\n"
+"Extend the right side of the deque with elements from the iterable.");
+
+#define DEQUE_EXTEND_METHODDEF \
+ {"extend", (PyCFunction)deque_extend, METH_O, deque_extend__doc__},
+
+PyDoc_STRVAR(deque_extendleft__doc__,
+"extendleft($self, iterable, /)\n"
+"--\n"
+"\n"
+"Extend the left side of the deque with elements from the iterable.");
+
+#define DEQUE_EXTENDLEFT_METHODDEF \
+ {"extendleft", (PyCFunction)deque_extendleft, METH_O, deque_extendleft__doc__},
+
+PyDoc_STRVAR(deque_copy__doc__,
+"copy($self, /)\n"
+"--\n"
+"\n"
+"Return a shallow copy of a deque.");
+
+#define DEQUE_COPY_METHODDEF \
+ {"copy", (PyCFunction)deque_copy, METH_NOARGS, deque_copy__doc__},
+
+static PyObject *
+deque_copy_impl(dequeobject *deque);
+
+static PyObject *
+deque_copy(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque_copy_impl(deque);
+}
+
+PyDoc_STRVAR(deque___copy____doc__,
+"__copy__($self, /)\n"
+"--\n"
+"\n"
+"Return a shallow copy of a deque.");
+
+#define DEQUE___COPY___METHODDEF \
+ {"__copy__", (PyCFunction)deque___copy__, METH_NOARGS, deque___copy____doc__},
+
+static PyObject *
+deque___copy___impl(dequeobject *deque);
+
+static PyObject *
+deque___copy__(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque___copy___impl(deque);
+}
+
+PyDoc_STRVAR(deque_clearmethod__doc__,
+"clear($self, /)\n"
+"--\n"
+"\n"
+"Remove all elements from the deque.");
+
+#define DEQUE_CLEARMETHOD_METHODDEF \
+ {"clear", (PyCFunction)deque_clearmethod, METH_NOARGS, deque_clearmethod__doc__},
+
+static PyObject *
+deque_clearmethod_impl(dequeobject *deque);
+
+static PyObject *
+deque_clearmethod(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque_clearmethod_impl(deque);
+}
+
+PyDoc_STRVAR(deque_rotate__doc__,
+"rotate($self, n=1, /)\n"
+"--\n"
+"\n"
+"Rotate the deque n steps to the right. If n is negative, rotates left.");
+
+#define DEQUE_ROTATE_METHODDEF \
+ {"rotate", _PyCFunction_CAST(deque_rotate), METH_FASTCALL, deque_rotate__doc__},
+
+static PyObject *
+deque_rotate_impl(dequeobject *deque, Py_ssize_t n);
+
+static PyObject *
+deque_rotate(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
+{
+ PyObject *return_value = NULL;
+ Py_ssize_t n = 1;
+
+ if (!_PyArg_CheckPositional("rotate", nargs, 0, 1)) {
+ goto exit;
+ }
+ if (nargs < 1) {
+ goto skip_optional;
+ }
+ {
+ Py_ssize_t ival = -1;
+ PyObject *iobj = _PyNumber_Index(args[0]);
+ if (iobj != NULL) {
+ ival = PyLong_AsSsize_t(iobj);
+ Py_DECREF(iobj);
+ }
+ if (ival == -1 && PyErr_Occurred()) {
+ goto exit;
+ }
+ n = ival;
+ }
+skip_optional:
+ return_value = deque_rotate_impl(deque, n);
+
+exit:
+ return return_value;
+}
+
+PyDoc_STRVAR(deque_reverse__doc__,
+"reverse($self, /)\n"
+"--\n"
+"\n"
+"Reverse *IN PLACE*.");
+
+#define DEQUE_REVERSE_METHODDEF \
+ {"reverse", (PyCFunction)deque_reverse, METH_NOARGS, deque_reverse__doc__},
+
+static PyObject *
+deque_reverse_impl(dequeobject *deque);
+
+static PyObject *
+deque_reverse(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque_reverse_impl(deque);
+}
+
+PyDoc_STRVAR(deque_count__doc__,
+"count($self, value, /)\n"
+"--\n"
+"\n"
+"Return number of occurrences of value.");
+
+#define DEQUE_COUNT_METHODDEF \
+ {"count", (PyCFunction)deque_count, METH_O, deque_count__doc__},
+
+PyDoc_STRVAR(deque_index__doc__,
+"index($self, value, [start, [stop]])\n"
+"--\n"
+"\n"
+"Return first index of value.\n"
+"\n"
+"Raises ValueError if the value is not present.");
+
+#define DEQUE_INDEX_METHODDEF \
+ {"index", _PyCFunction_CAST(deque_index), METH_FASTCALL, deque_index__doc__},
+
+static PyObject *
+deque_index_impl(dequeobject *deque, PyObject *v, Py_ssize_t start,
+ Py_ssize_t stop);
+
+static PyObject *
+deque_index(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
+{
+ PyObject *return_value = NULL;
+ PyObject *v;
+ Py_ssize_t start = 0;
+ Py_ssize_t stop = Py_SIZE(deque);
+
+ if (!_PyArg_CheckPositional("index", nargs, 1, 3)) {
+ goto exit;
+ }
+ v = args[0];
+ if (nargs < 2) {
+ goto skip_optional;
+ }
+ if (!_PyEval_SliceIndexNotNone(args[1], &start)) {
+ goto exit;
+ }
+ if (nargs < 3) {
+ goto skip_optional;
+ }
+ if (!_PyEval_SliceIndexNotNone(args[2], &stop)) {
+ goto exit;
+ }
+skip_optional:
+ return_value = deque_index_impl(deque, v, start, stop);
+
+exit:
+ return return_value;
+}
+
+PyDoc_STRVAR(deque_insert__doc__,
+"insert($self, index, value, /)\n"
+"--\n"
+"\n"
+"Insert value before index.");
+
+#define DEQUE_INSERT_METHODDEF \
+ {"insert", _PyCFunction_CAST(deque_insert), METH_FASTCALL, deque_insert__doc__},
+
+static PyObject *
+deque_insert_impl(dequeobject *deque, Py_ssize_t index, PyObject *value);
+
+static PyObject *
+deque_insert(dequeobject *deque, PyObject *const *args, Py_ssize_t nargs)
+{
+ PyObject *return_value = NULL;
+ Py_ssize_t index;
+ PyObject *value;
+
+ if (!_PyArg_CheckPositional("insert", nargs, 2, 2)) {
+ goto exit;
+ }
+ {
+ Py_ssize_t ival = -1;
+ PyObject *iobj = _PyNumber_Index(args[0]);
+ if (iobj != NULL) {
+ ival = PyLong_AsSsize_t(iobj);
+ Py_DECREF(iobj);
+ }
+ if (ival == -1 && PyErr_Occurred()) {
+ goto exit;
+ }
+ index = ival;
+ }
+ value = args[1];
+ return_value = deque_insert_impl(deque, index, value);
+
+exit:
+ return return_value;
+}
+
+PyDoc_STRVAR(deque_remove__doc__,
+"remove($self, value, /)\n"
+"--\n"
+"\n"
+"Remove first occurrence of value.");
+
+#define DEQUE_REMOVE_METHODDEF \
+ {"remove", (PyCFunction)deque_remove, METH_O, deque_remove__doc__},
+
+PyDoc_STRVAR(deque___reduce____doc__,
+"__reduce__($self, /)\n"
+"--\n"
+"\n"
+"Return state information for pickling.");
+
+#define DEQUE___REDUCE___METHODDEF \
+ {"__reduce__", (PyCFunction)deque___reduce__, METH_NOARGS, deque___reduce____doc__},
+
+static PyObject *
+deque___reduce___impl(dequeobject *deque);
+
+static PyObject *
+deque___reduce__(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque___reduce___impl(deque);
+}
+
+PyDoc_STRVAR(deque_init__doc__,
+"deque([iterable[, maxlen]])\n"
+"--\n"
+"\n"
+"A list-like sequence optimized for data accesses near its endpoints.");
+
+static int
+deque_init_impl(dequeobject *deque, PyObject *iterable, PyObject *maxlenobj);
+
+static int
+deque_init(PyObject *deque, PyObject *args, PyObject *kwargs)
+{
+ int return_value = -1;
+ #if defined(Py_BUILD_CORE) && !defined(Py_BUILD_CORE_MODULE)
+
+ #define NUM_KEYWORDS 2
+ static struct {
+ PyGC_Head _this_is_not_used;
+ PyObject_VAR_HEAD
+ PyObject *ob_item[NUM_KEYWORDS];
+ } _kwtuple = {
+ .ob_base = PyVarObject_HEAD_INIT(&PyTuple_Type, NUM_KEYWORDS)
+ .ob_item = { &_Py_ID(iterable), &_Py_ID(maxlen), },
+ };
+ #undef NUM_KEYWORDS
+ #define KWTUPLE (&_kwtuple.ob_base.ob_base)
+
+ #else // !Py_BUILD_CORE
+ # define KWTUPLE NULL
+ #endif // !Py_BUILD_CORE
+
+ static const char * const _keywords[] = {"iterable", "maxlen", NULL};
+ static _PyArg_Parser _parser = {
+ .keywords = _keywords,
+ .fname = "deque",
+ .kwtuple = KWTUPLE,
+ };
+ #undef KWTUPLE
+ PyObject *argsbuf[2];
+ PyObject * const *fastargs;
+ Py_ssize_t nargs = PyTuple_GET_SIZE(args);
+ Py_ssize_t noptargs = nargs + (kwargs ? PyDict_GET_SIZE(kwargs) : 0) - 0;
+ PyObject *iterable = NULL;
+ PyObject *maxlenobj = NULL;
+
+ fastargs = _PyArg_UnpackKeywords(_PyTuple_CAST(args)->ob_item, nargs, kwargs, NULL, &_parser, 0, 2, 0, argsbuf);
+ if (!fastargs) {
+ goto exit;
+ }
+ if (!noptargs) {
+ goto skip_optional_pos;
+ }
+ if (fastargs[0]) {
+ iterable = fastargs[0];
+ if (!--noptargs) {
+ goto skip_optional_pos;
+ }
+ }
+ maxlenobj = fastargs[1];
+skip_optional_pos:
+ return_value = deque_init_impl((dequeobject *)deque, iterable, maxlenobj);
+
+exit:
+ return return_value;
+}
+
+PyDoc_STRVAR(deque___sizeof____doc__,
+"__sizeof__($self, /)\n"
+"--\n"
+"\n"
+"Return the size of the deque in memory, in bytes.");
+
+#define DEQUE___SIZEOF___METHODDEF \
+ {"__sizeof__", (PyCFunction)deque___sizeof__, METH_NOARGS, deque___sizeof____doc__},
+
+static PyObject *
+deque___sizeof___impl(dequeobject *deque);
+
+static PyObject *
+deque___sizeof__(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque___sizeof___impl(deque);
+}
+
+PyDoc_STRVAR(deque___reversed____doc__,
+"__reversed__($self, /)\n"
+"--\n"
+"\n"
+"Return a reverse iterator over the deque.");
+
+#define DEQUE___REVERSED___METHODDEF \
+ {"__reversed__", (PyCFunction)deque___reversed__, METH_NOARGS, deque___reversed____doc__},
+
+static PyObject *
+deque___reversed___impl(dequeobject *deque);
+
+static PyObject *
+deque___reversed__(dequeobject *deque, PyObject *Py_UNUSED(ignored))
+{
+ return deque___reversed___impl(deque);
+}
+
PyDoc_STRVAR(_collections__count_elements__doc__,
"_count_elements($module, mapping, iterable, /)\n"
"--\n"
@@ -72,4 +488,4 @@ tuplegetter_new(PyTypeObject *type, PyObject *args, PyObject *kwargs)
exit:
return return_value;
}
-/*[clinic end generated code: output=c896a72f8c45930d input=a9049054013a1b77]*/
+/*[clinic end generated code: output=3633a5cbc23e8440 input=a9049054013a1b77]*/
1
0
https://github.com/python/cpython/commit/e8b8f5e9c2da6a436360ce648061c90bdf…
commit: e8b8f5e9c2da6a436360ce648061c90bdfcba863
branch: main
author: Skip Montanaro <skip.montanaro(a)gmail.com>
committer: serhiy-storchaka <storchaka(a)gmail.com>
date: 2024-01-29T16:43:44+02:00
summary:
gh-101100: Fix datetime reference warnings (GH-114661)
Co-authored-by: Serhiy Storchaka <storchaka(a)gmail.com>
files:
M Doc/conf.py
M Doc/library/datetime.rst
M Doc/tools/.nitignore
diff --git a/Doc/conf.py b/Doc/conf.py
index 458954370debe2..a96e7787d167a3 100644
--- a/Doc/conf.py
+++ b/Doc/conf.py
@@ -89,20 +89,25 @@
nitpick_ignore = [
# Standard C functions
('c:func', 'calloc'),
+ ('c:func', 'ctime'),
('c:func', 'dlopen'),
('c:func', 'exec'),
('c:func', 'fcntl'),
('c:func', 'fork'),
('c:func', 'free'),
+ ('c:func', 'gettimeofday'),
('c:func', 'gmtime'),
+ ('c:func', 'localeconv'),
('c:func', 'localtime'),
('c:func', 'main'),
('c:func', 'malloc'),
+ ('c:func', 'mktime'),
('c:func', 'printf'),
('c:func', 'realloc'),
('c:func', 'snprintf'),
('c:func', 'sprintf'),
('c:func', 'stat'),
+ ('c:func', 'strftime'),
('c:func', 'system'),
('c:func', 'time'),
('c:func', 'vsnprintf'),
diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst
index b36f8c19cd6040..47ecb0ba331bdc 100644
--- a/Doc/library/datetime.rst
+++ b/Doc/library/datetime.rst
@@ -14,7 +14,7 @@
.. XXX what order should the types be discussed in?
-The :mod:`datetime` module supplies classes for manipulating dates and times.
+The :mod:`!datetime` module supplies classes for manipulating dates and times.
While date and time arithmetic is supported, the focus of the implementation is
on efficient attribute extraction for output formatting and manipulation.
@@ -70,7 +70,7 @@ These :class:`tzinfo` objects capture information about the offset from UTC
time, the time zone name, and whether daylight saving time is in effect.
Only one concrete :class:`tzinfo` class, the :class:`timezone` class, is
-supplied by the :mod:`datetime` module. The :class:`timezone` class can
+supplied by the :mod:`!datetime` module. The :class:`timezone` class can
represent simple timezones with fixed offsets from UTC, such as UTC itself or
North American EST and EDT timezones. Supporting timezones at deeper levels of
detail is up to the application. The rules for time adjustment across the
@@ -80,7 +80,7 @@ standard suitable for every application aside from UTC.
Constants
---------
-The :mod:`datetime` module exports the following constants:
+The :mod:`!datetime` module exports the following constants:
.. data:: MINYEAR
@@ -631,7 +631,7 @@ Notes:
date2.toordinal()``. Date comparison raises :exc:`TypeError` if
the other comparand isn't also a :class:`date` object. However,
``NotImplemented`` is returned instead if the other comparand has a
- :meth:`timetuple` attribute. This hook gives other kinds of date objects a
+ :attr:`~date.timetuple` attribute. This hook gives other kinds of date objects a
chance at implementing mixed-type comparison. If not, when a :class:`date`
object is compared to an object of a different type, :exc:`TypeError` is raised
unless the comparison is ``==`` or ``!=``. The latter cases return
@@ -1215,7 +1215,7 @@ Supported operations:
object addresses, datetime comparison normally raises :exc:`TypeError` if the
other comparand isn't also a :class:`.datetime` object. However,
``NotImplemented`` is returned instead if the other comparand has a
- :meth:`timetuple` attribute. This hook gives other kinds of date objects a
+ :attr:`~.datetime.timetuple` attribute. This hook gives other kinds of date objects a
chance at implementing mixed-type comparison. If not, when a :class:`.datetime`
object is compared to an object of a different type, :exc:`TypeError` is raised
unless the comparison is ``==`` or ``!=``. The latter cases return
@@ -1347,22 +1347,22 @@ Instance methods:
where ``yday = d.toordinal() - date(d.year, 1, 1).toordinal() + 1``
is the day number within the current year starting with ``1`` for January
- 1st. The :attr:`tm_isdst` flag of the result is set according to the
+ 1st. The :attr:`~time.struct_time.tm_isdst` flag of the result is set according to the
:meth:`dst` method: :attr:`.tzinfo` is ``None`` or :meth:`dst` returns
- ``None``, :attr:`tm_isdst` is set to ``-1``; else if :meth:`dst` returns a
- non-zero value, :attr:`tm_isdst` is set to ``1``; else :attr:`tm_isdst` is
+ ``None``, :attr:`!tm_isdst` is set to ``-1``; else if :meth:`dst` returns a
+ non-zero value, :attr:`!tm_isdst` is set to ``1``; else :attr:`!tm_isdst` is
set to ``0``.
.. method:: datetime.utctimetuple()
If :class:`.datetime` instance *d* is naive, this is the same as
- ``d.timetuple()`` except that :attr:`tm_isdst` is forced to 0 regardless of what
+ ``d.timetuple()`` except that :attr:`~.time.struct_time.tm_isdst` is forced to 0 regardless of what
``d.dst()`` returns. DST is never in effect for a UTC time.
If *d* is aware, *d* is normalized to UTC time, by subtracting
``d.utcoffset()``, and a :class:`time.struct_time` for the
- normalized time is returned. :attr:`tm_isdst` is forced to 0. Note
+ normalized time is returned. :attr:`!tm_isdst` is forced to 0. Note
that an :exc:`OverflowError` may be raised if *d*.year was
``MINYEAR`` or ``MAXYEAR`` and UTC adjustment spills over a year
boundary.
@@ -1550,7 +1550,7 @@ Instance methods:
Examples of Usage: :class:`.datetime`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Examples of working with :class:`~datetime.datetime` objects:
+Examples of working with :class:`.datetime` objects:
.. doctest::
@@ -1761,9 +1761,9 @@ is aware, :exc:`TypeError` is raised if an order comparison is attempted. For eq
comparisons, naive instances are never equal to aware instances.
If both comparands are aware, and have
-the same :attr:`~time.tzinfo` attribute, the common :attr:`~time.tzinfo` attribute is
+the same :attr:`~.time.tzinfo` attribute, the common :attr:`!tzinfo` attribute is
ignored and the base times are compared. If both comparands are aware and
-have different :attr:`~time.tzinfo` attributes, the comparands are first adjusted by
+have different :attr:`!tzinfo` attributes, the comparands are first adjusted by
subtracting their UTC offsets (obtained from ``self.utcoffset()``). In order
to stop mixed-type comparisons from falling back to the default comparison by
object address, when a :class:`.time` object is compared to an object of a
@@ -1771,7 +1771,7 @@ different type, :exc:`TypeError` is raised unless the comparison is ``==`` or
``!=``. The latter cases return :const:`False` or :const:`True`, respectively.
.. versionchanged:: 3.3
- Equality comparisons between aware and naive :class:`~datetime.time` instances
+ Equality comparisons between aware and naive :class:`.time` instances
don't raise :exc:`TypeError`.
In Boolean contexts, a :class:`.time` object is always considered to be true.
@@ -1981,7 +1981,7 @@ Examples of working with a :class:`.time` object::
You need to derive a concrete subclass, and (at least)
supply implementations of the standard :class:`tzinfo` methods needed by the
- :class:`.datetime` methods you use. The :mod:`datetime` module provides
+ :class:`.datetime` methods you use. The :mod:`!datetime` module provides
:class:`timezone`, a simple concrete subclass of :class:`tzinfo` which can
represent timezones with fixed offset from UTC such as UTC itself or North
American EST and EDT.
@@ -1994,7 +1994,7 @@ Examples of working with a :class:`.time` object::
A concrete subclass of :class:`tzinfo` may need to implement the following
methods. Exactly which methods are needed depends on the uses made of aware
- :mod:`datetime` objects. If in doubt, simply implement all of them.
+ :mod:`!datetime` objects. If in doubt, simply implement all of them.
.. method:: tzinfo.utcoffset(dt)
@@ -2035,7 +2035,7 @@ Examples of working with a :class:`.time` object::
already been added to the UTC offset returned by :meth:`utcoffset`, so there's
no need to consult :meth:`dst` unless you're interested in obtaining DST info
separately. For example, :meth:`datetime.timetuple` calls its :attr:`~.datetime.tzinfo`
- attribute's :meth:`dst` method to determine how the :attr:`tm_isdst` flag
+ attribute's :meth:`dst` method to determine how the :attr:`~time.struct_time.tm_isdst` flag
should be set, and :meth:`tzinfo.fromutc` calls :meth:`dst` to account for
DST changes when crossing time zones.
@@ -2051,7 +2051,7 @@ Examples of working with a :class:`.time` object::
relies on this, but cannot detect violations; it's the programmer's
responsibility to ensure it. If a :class:`tzinfo` subclass cannot guarantee
this, it may be able to override the default implementation of
- :meth:`tzinfo.fromutc` to work correctly with :meth:`astimezone` regardless.
+ :meth:`tzinfo.fromutc` to work correctly with :meth:`~.datetime.astimezone` regardless.
Most implementations of :meth:`dst` will probably look like one of these two::
@@ -2080,7 +2080,7 @@ Examples of working with a :class:`.time` object::
.. method:: tzinfo.tzname(dt)
Return the time zone name corresponding to the :class:`.datetime` object *dt*, as
- a string. Nothing about string names is defined by the :mod:`datetime` module,
+ a string. Nothing about string names is defined by the :mod:`!datetime` module,
and there's no requirement that it mean anything in particular. For example,
"GMT", "UTC", "-500", "-5:00", "EDT", "US/Eastern", "America/New York" are all
valid replies. Return ``None`` if a string name isn't known. Note that this is
@@ -2128,7 +2128,7 @@ There is one more :class:`tzinfo` method that a subclass may wish to override:
different years. An example of a time zone the default :meth:`fromutc`
implementation may not handle correctly in all cases is one where the standard
offset (from UTC) depends on the specific date and time passed, which can happen
- for political reasons. The default implementations of :meth:`astimezone` and
+ for political reasons. The default implementations of :meth:`~.datetime.astimezone` and
:meth:`fromutc` may not produce the result you want if the result is one of the
hours straddling the moment the standard offset changes.
@@ -2194,10 +2194,10 @@ hour that can't be spelled unambiguously in local wall time: the last hour of
daylight time. In Eastern, that's times of the form 5:MM UTC on the day
daylight time ends. The local wall clock leaps from 1:59 (daylight time) back
to 1:00 (standard time) again. Local times of the form 1:MM are ambiguous.
-:meth:`astimezone` mimics the local clock's behavior by mapping two adjacent UTC
+:meth:`~.datetime.astimezone` mimics the local clock's behavior by mapping two adjacent UTC
hours into the same local hour then. In the Eastern example, UTC times of the
form 5:MM and 6:MM both map to 1:MM when converted to Eastern, but earlier times
-have the :attr:`~datetime.fold` attribute set to 0 and the later times have it set to 1.
+have the :attr:`~.datetime.fold` attribute set to 0 and the later times have it set to 1.
For example, at the Fall back transition of 2016, we get::
>>> u0 = datetime(2016, 11, 6, 4, tzinfo=timezone.utc)
@@ -2212,10 +2212,10 @@ For example, at the Fall back transition of 2016, we get::
07:00:00 UTC = 02:00:00 EST 0
Note that the :class:`.datetime` instances that differ only by the value of the
-:attr:`~datetime.fold` attribute are considered equal in comparisons.
+:attr:`~.datetime.fold` attribute are considered equal in comparisons.
Applications that can't bear wall-time ambiguities should explicitly check the
-value of the :attr:`~datetime.fold` attribute or avoid using hybrid
+value of the :attr:`~.datetime.fold` attribute or avoid using hybrid
:class:`tzinfo` subclasses; there are no ambiguities when using :class:`timezone`,
or any other fixed-offset :class:`tzinfo` subclass (such as a class representing
only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).
@@ -2223,7 +2223,7 @@ only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).
.. seealso::
:mod:`zoneinfo`
- The :mod:`datetime` module has a basic :class:`timezone` class (for
+ The :mod:`!datetime` module has a basic :class:`timezone` class (for
handling arbitrary fixed offsets from UTC) and its :attr:`timezone.utc`
attribute (a UTC timezone instance).
@@ -2241,7 +2241,7 @@ only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).
.. _datetime-timezone:
:class:`timezone` Objects
---------------------------
+-------------------------
The :class:`timezone` class is a subclass of :class:`tzinfo`, each
instance of which represents a timezone defined by a fixed offset from
@@ -2316,8 +2316,8 @@ Class attributes:
.. _strftime-strptime-behavior:
-:meth:`strftime` and :meth:`strptime` Behavior
-----------------------------------------------
+:meth:`~.datetime.strftime` and :meth:`~.datetime.strptime` Behavior
+--------------------------------------------------------------------
:class:`date`, :class:`.datetime`, and :class:`.time` objects all support a
``strftime(format)`` method, to create a string representing the time under the
@@ -2327,8 +2327,8 @@ Conversely, the :meth:`datetime.strptime` class method creates a
:class:`.datetime` object from a string representing a date and time and a
corresponding format string.
-The table below provides a high-level comparison of :meth:`strftime`
-versus :meth:`strptime`:
+The table below provides a high-level comparison of :meth:`~.datetime.strftime`
+versus :meth:`~.datetime.strptime`:
+----------------+--------------------------------------------------------+------------------------------------------------------------------------------+
| | ``strftime`` | ``strptime`` |
@@ -2345,8 +2345,8 @@ versus :meth:`strptime`:
.. _format-codes:
-:meth:`strftime` and :meth:`strptime` Format Codes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:meth:`~.datetime.strftime` and :meth:`~.datetime.strptime` Format Codes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These methods accept format codes that can be used to parse and format dates::
@@ -2485,13 +2485,13 @@ convenience. These parameters all correspond to ISO 8601 date values.
| | naive). | -03:07:12.345216 | |
+-----------+--------------------------------+------------------------+-------+
-These may not be available on all platforms when used with the :meth:`strftime`
+These may not be available on all platforms when used with the :meth:`~.datetime.strftime`
method. The ISO 8601 year and ISO 8601 week directives are not interchangeable
-with the year and week number directives above. Calling :meth:`strptime` with
+with the year and week number directives above. Calling :meth:`~.datetime.strptime` with
incomplete or ambiguous ISO 8601 directives will raise a :exc:`ValueError`.
The full set of format codes supported varies across platforms, because Python
-calls the platform C library's :func:`strftime` function, and platform
+calls the platform C library's :c:func:`strftime` function, and platform
variations are common. To see the full set of format codes supported on your
platform, consult the :manpage:`strftime(3)` documentation. There are also
differences between platforms in handling of unsupported format specifiers.
@@ -2507,9 +2507,9 @@ Technical Detail
Broadly speaking, ``d.strftime(fmt)`` acts like the :mod:`time` module's
``time.strftime(fmt, d.timetuple())`` although not all objects support a
-:meth:`timetuple` method.
+:meth:`~date.timetuple` method.
-For the :meth:`datetime.strptime` class method, the default value is
+For the :meth:`.datetime.strptime` class method, the default value is
``1900-01-01T00:00:00.000``: any components not specified in the format string
will be pulled from the default value. [#]_
@@ -2544,27 +2544,27 @@ Notes:
contain non-ASCII characters.
(2)
- The :meth:`strptime` method can parse years in the full [1, 9999] range, but
+ The :meth:`~.datetime.strptime` method can parse years in the full [1, 9999] range, but
years < 1000 must be zero-filled to 4-digit width.
.. versionchanged:: 3.2
- In previous versions, :meth:`strftime` method was restricted to
+ In previous versions, :meth:`~.datetime.strftime` method was restricted to
years >= 1900.
.. versionchanged:: 3.3
- In version 3.2, :meth:`strftime` method was restricted to
+ In version 3.2, :meth:`~.datetime.strftime` method was restricted to
years >= 1000.
(3)
- When used with the :meth:`strptime` method, the ``%p`` directive only affects
+ When used with the :meth:`~.datetime.strptime` method, the ``%p`` directive only affects
the output hour field if the ``%I`` directive is used to parse the hour.
(4)
- Unlike the :mod:`time` module, the :mod:`datetime` module does not support
+ Unlike the :mod:`time` module, the :mod:`!datetime` module does not support
leap seconds.
(5)
- When used with the :meth:`strptime` method, the ``%f`` directive
+ When used with the :meth:`~.datetime.strptime` method, the ``%f`` directive
accepts from one to six digits and zero pads on the right. ``%f`` is
an extension to the set of format characters in the C standard (but
implemented separately in datetime objects, and therefore always
@@ -2577,7 +2577,7 @@ Notes:
For an aware object:
``%z``
- :meth:`utcoffset` is transformed into a string of the form
+ :meth:`~.datetime.utcoffset` is transformed into a string of the form
``±HHMM[SS[.ffffff]]``, where ``HH`` is a 2-digit string giving the number
of UTC offset hours, ``MM`` is a 2-digit string giving the number of UTC
offset minutes, ``SS`` is a 2-digit string giving the number of UTC offset
@@ -2585,14 +2585,14 @@ Notes:
offset microseconds. The ``ffffff`` part is omitted when the offset is a
whole number of seconds and both the ``ffffff`` and the ``SS`` part is
omitted when the offset is a whole number of minutes. For example, if
- :meth:`utcoffset` returns ``timedelta(hours=-3, minutes=-30)``, ``%z`` is
+ :meth:`~.datetime.utcoffset` returns ``timedelta(hours=-3, minutes=-30)``, ``%z`` is
replaced with the string ``'-0330'``.
.. versionchanged:: 3.7
The UTC offset is not restricted to a whole number of minutes.
.. versionchanged:: 3.7
- When the ``%z`` directive is provided to the :meth:`strptime` method,
+ When the ``%z`` directive is provided to the :meth:`~.datetime.strptime` method,
the UTC offsets can have a colon as a separator between hours, minutes
and seconds.
For example, ``'+01:00:00'`` will be parsed as an offset of one hour.
@@ -2603,11 +2603,11 @@ Notes:
hours, minutes and seconds.
``%Z``
- In :meth:`strftime`, ``%Z`` is replaced by an empty string if
- :meth:`tzname` returns ``None``; otherwise ``%Z`` is replaced by the
+ In :meth:`~.datetime.strftime`, ``%Z`` is replaced by an empty string if
+ :meth:`~.datetime.tzname` returns ``None``; otherwise ``%Z`` is replaced by the
returned value, which must be a string.
- :meth:`strptime` only accepts certain values for ``%Z``:
+ :meth:`~.datetime.strptime` only accepts certain values for ``%Z``:
1. any value in ``time.tzname`` for your machine's locale
2. the hard-coded values ``UTC`` and ``GMT``
@@ -2617,23 +2617,23 @@ Notes:
invalid values.
.. versionchanged:: 3.2
- When the ``%z`` directive is provided to the :meth:`strptime` method, an
+ When the ``%z`` directive is provided to the :meth:`~.datetime.strptime` method, an
aware :class:`.datetime` object will be produced. The ``tzinfo`` of the
result will be set to a :class:`timezone` instance.
(7)
- When used with the :meth:`strptime` method, ``%U`` and ``%W`` are only used
+ When used with the :meth:`~.datetime.strptime` method, ``%U`` and ``%W`` are only used
in calculations when the day of the week and the calendar year (``%Y``)
are specified.
(8)
Similar to ``%U`` and ``%W``, ``%V`` is only used in calculations when the
day of the week and the ISO year (``%G``) are specified in a
- :meth:`strptime` format string. Also note that ``%G`` and ``%Y`` are not
+ :meth:`~.datetime.strptime` format string. Also note that ``%G`` and ``%Y`` are not
interchangeable.
(9)
- When used with the :meth:`strptime` method, the leading zero is optional
+ When used with the :meth:`~.datetime.strptime` method, the leading zero is optional
for formats ``%d``, ``%m``, ``%H``, ``%I``, ``%M``, ``%S``, ``%j``, ``%U``,
``%W``, and ``%V``. Format ``%y`` does require a leading zero.
diff --git a/Doc/tools/.nitignore b/Doc/tools/.nitignore
index 763503205e1670..bba4fe0d5f2425 100644
--- a/Doc/tools/.nitignore
+++ b/Doc/tools/.nitignore
@@ -26,7 +26,6 @@ Doc/library/asyncio-subprocess.rst
Doc/library/bdb.rst
Doc/library/collections.rst
Doc/library/csv.rst
-Doc/library/datetime.rst
Doc/library/dbm.rst
Doc/library/decimal.rst
Doc/library/email.charset.rst
1
0
![](https://secure.gravatar.com/avatar/cc7737cd64a84f1b5c61a160798e97ee.jpg?s=120&d=mm&r=g)
29 Jan '24
https://github.com/python/cpython/commit/07d68ea843d6251efcdadc167cd7840112…
commit: 07d68ea843d6251efcdadc167cd7840112bc13d2
branch: 3.11
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: encukou <encukou(a)gmail.com>
date: 2024-01-29T14:25:52Z
summary:
[3.11] gh-89159: Add some TarFile attribute types (GH-114520) (GH-114715)
(cherry picked from commit d7d0d13cd37651990586d31d8974c59bd25e1045)
Co-authored-by: Stanley <46876382+slateny(a)users.noreply.github.com>
files:
M Doc/library/tarfile.rst
diff --git a/Doc/library/tarfile.rst b/Doc/library/tarfile.rst
index cd2df3e69e3729..32d77d5d87bf82 100644
--- a/Doc/library/tarfile.rst
+++ b/Doc/library/tarfile.rst
@@ -660,6 +660,7 @@ be finalized; only the internally used file object will be closed. See the
.. attribute:: TarFile.pax_headers
+ :type: dict
A dictionary containing key-value pairs of pax global headers.
@@ -830,26 +831,31 @@ A ``TarInfo`` object has the following public data attributes:
attribute.
.. attribute:: TarInfo.chksum
+ :type: int
Header checksum.
.. attribute:: TarInfo.devmajor
+ :type: int
Device major number.
.. attribute:: TarInfo.devminor
+ :type: int
Device minor number.
.. attribute:: TarInfo.offset
+ :type: int
The tar header starts here.
.. attribute:: TarInfo.offset_data
+ :type: int
The file's data starts here.
1
0
![](https://secure.gravatar.com/avatar/cc7737cd64a84f1b5c61a160798e97ee.jpg?s=120&d=mm&r=g)
29 Jan '24
https://github.com/python/cpython/commit/0795d9a17a4c95cdb6dd032efb9ebf193f…
commit: 0795d9a17a4c95cdb6dd032efb9ebf193f7fb274
branch: 3.12
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: encukou <encukou(a)gmail.com>
date: 2024-01-29T14:25:46Z
summary:
[3.12] gh-89159: Add some TarFile attribute types (GH-114520) (GH-114714)
(cherry picked from commit d7d0d13cd37651990586d31d8974c59bd25e1045)
Co-authored-by: Stanley <46876382+slateny(a)users.noreply.github.com>
files:
M Doc/library/tarfile.rst
diff --git a/Doc/library/tarfile.rst b/Doc/library/tarfile.rst
index dbbcb127f6f209..755581cfc6f640 100644
--- a/Doc/library/tarfile.rst
+++ b/Doc/library/tarfile.rst
@@ -668,6 +668,7 @@ be finalized; only the internally used file object will be closed. See the
.. attribute:: TarFile.pax_headers
+ :type: dict
A dictionary containing key-value pairs of pax global headers.
@@ -833,26 +834,31 @@ A ``TarInfo`` object has the following public data attributes:
attribute.
.. attribute:: TarInfo.chksum
+ :type: int
Header checksum.
.. attribute:: TarInfo.devmajor
+ :type: int
Device major number.
.. attribute:: TarInfo.devminor
+ :type: int
Device minor number.
.. attribute:: TarInfo.offset
+ :type: int
The tar header starts here.
.. attribute:: TarInfo.offset_data
+ :type: int
The file's data starts here.
1
0
![](https://secure.gravatar.com/avatar/cc7737cd64a84f1b5c61a160798e97ee.jpg?s=120&d=mm&r=g)
[3.11] gh-101100: Fix Sphinx warnings in `whatsnew/2.2.rst` (GH-112366) (#114712)
by hugovk 29 Jan '24
by hugovk 29 Jan '24
29 Jan '24
https://github.com/python/cpython/commit/ca9a7fc24f606a4b2daa6d23297d9e0c33…
commit: ca9a7fc24f606a4b2daa6d23297d9e0c33a36d8e
branch: 3.11
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: hugovk <1324225+hugovk(a)users.noreply.github.com>
date: 2024-01-29T13:18:59Z
summary:
[3.11] gh-101100: Fix Sphinx warnings in `whatsnew/2.2.rst` (GH-112366) (#114712)
Co-authored-by: Hugo van Kemenade <1324225+hugovk(a)users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <hugovk(a)users.noreply.github.com>
files:
M Doc/tools/.nitignore
M Doc/whatsnew/2.2.rst
diff --git a/Doc/tools/.nitignore b/Doc/tools/.nitignore
index 76fbc3c3d4d71f..d7261fe2922e73 100644
--- a/Doc/tools/.nitignore
+++ b/Doc/tools/.nitignore
@@ -95,7 +95,6 @@ Doc/tutorial/datastructures.rst
Doc/using/windows.rst
Doc/whatsnew/2.0.rst
Doc/whatsnew/2.1.rst
-Doc/whatsnew/2.2.rst
Doc/whatsnew/2.4.rst
Doc/whatsnew/2.5.rst
Doc/whatsnew/2.6.rst
diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index 6efc23a82de923..968bd7a126bdf0 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -53,9 +53,9 @@ A long time ago I wrote a web page listing flaws in Python's design. One of the
most significant flaws was that it's impossible to subclass Python types
implemented in C. In particular, it's not possible to subclass built-in types,
so you can't just subclass, say, lists in order to add a single useful method to
-them. The :mod:`UserList` module provides a class that supports all of the
+them. The :mod:`!UserList` module provides a class that supports all of the
methods of lists and that can be subclassed further, but there's lots of C code
-that expects a regular Python list and won't accept a :class:`UserList`
+that expects a regular Python list and won't accept a :class:`!UserList`
instance.
Python 2.2 fixes this, and in the process adds some exciting new capabilities.
@@ -69,7 +69,7 @@ A brief summary:
* It's also possible to automatically call methods on accessing or setting an
instance attribute by using a new mechanism called :dfn:`properties`. Many uses
- of :meth:`__getattr__` can be rewritten to use properties instead, making the
+ of :meth:`!__getattr__` can be rewritten to use properties instead, making the
resulting code simpler and faster. As a small side benefit, attributes can now
have docstrings, too.
@@ -120,7 +120,7 @@ added so if no built-in type is suitable, you can just subclass
This means that :keyword:`class` statements that don't have any base classes are
always classic classes in Python 2.2. (Actually you can also change this by
-setting a module-level variable named :attr:`__metaclass__` --- see :pep:`253`
+setting a module-level variable named :attr:`!__metaclass__` --- see :pep:`253`
for the details --- but it's easier to just subclass :class:`object`.)
The type objects for the built-in types are available as built-ins, named using
@@ -134,8 +134,8 @@ type objects that behave as factories when called. ::
123
To make the set of types complete, new type objects such as :func:`dict` and
-:func:`file` have been added. Here's a more interesting example, adding a
-:meth:`lock` method to file objects::
+:func:`!file` have been added. Here's a more interesting example, adding a
+:meth:`!lock` method to file objects::
class LockableFile(file):
def lock (self, operation, length=0, start=0, whence=0):
@@ -146,7 +146,7 @@ To make the set of types complete, new type objects such as :func:`dict` and
The now-obsolete :mod:`!posixfile` module contained a class that emulated all of
a file object's methods and also added a :meth:`!lock` method, but this class
couldn't be passed to internal functions that expected a built-in file,
-something which is possible with our new :class:`LockableFile`.
+something which is possible with our new :class:`!LockableFile`.
Descriptors
@@ -154,11 +154,11 @@ Descriptors
In previous versions of Python, there was no consistent way to discover what
attributes and methods were supported by an object. There were some informal
-conventions, such as defining :attr:`__members__` and :attr:`__methods__`
+conventions, such as defining :attr:`!__members__` and :attr:`!__methods__`
attributes that were lists of names, but often the author of an extension type
or a class wouldn't bother to define them. You could fall back on inspecting
the :attr:`~object.__dict__` of an object, but when class inheritance or an arbitrary
-:meth:`__getattr__` hook were in use this could still be inaccurate.
+:meth:`!__getattr__` hook were in use this could still be inaccurate.
The one big idea underlying the new class model is that an API for describing
the attributes of an object using :dfn:`descriptors` has been formalized.
@@ -171,7 +171,7 @@ attributes of their own:
* :attr:`~definition.__name__` is the attribute's name.
-* :attr:`__doc__` is the attribute's docstring.
+* :attr:`!__doc__` is the attribute's docstring.
* ``__get__(object)`` is a method that retrieves the attribute value from
*object*.
@@ -186,7 +186,7 @@ are::
descriptor = obj.__class__.x
descriptor.__get__(obj)
-For methods, :meth:`descriptor.__get__` returns a temporary object that's
+For methods, :meth:`!descriptor.__get__` returns a temporary object that's
callable, and wraps up the instance and the method to be called on it. This is
also why static methods and class methods are now possible; they have
descriptors that wrap up just the method, or the method and the class. As a
@@ -204,7 +204,7 @@ methods are defined like this::
...
g = classmethod(g)
-The :func:`staticmethod` function takes the function :func:`f`, and returns it
+The :func:`staticmethod` function takes the function :func:`!f`, and returns it
wrapped up in a descriptor so it can be stored in the class object. You might
expect there to be special syntax for creating such methods (``def static f``,
``defstatic f()``, or something like that) but no such syntax has been defined
@@ -232,10 +232,10 @@ like this::
f = eiffelmethod(f, pre_f, post_f)
-Note that a person using the new :func:`eiffelmethod` doesn't have to understand
+Note that a person using the new :func:`!eiffelmethod` doesn't have to understand
anything about descriptors. This is why I think the new features don't increase
the basic complexity of the language. There will be a few wizards who need to
-know about it in order to write :func:`eiffelmethod` or the ZODB or whatever,
+know about it in order to write :func:`!eiffelmethod` or the ZODB or whatever,
but most users will just write code on top of the resulting libraries and ignore
the implementation details.
@@ -263,10 +263,10 @@ from :pep:`253` by Guido van Rossum)::
The lookup rule for classic classes is simple but not very smart; the base
classes are searched depth-first, going from left to right. A reference to
-:meth:`D.save` will search the classes :class:`D`, :class:`B`, and then
-:class:`A`, where :meth:`save` would be found and returned. :meth:`C.save`
-would never be found at all. This is bad, because if :class:`C`'s :meth:`save`
-method is saving some internal state specific to :class:`C`, not calling it will
+:meth:`!D.save` will search the classes :class:`!D`, :class:`!B`, and then
+:class:`!A`, where :meth:`!save` would be found and returned. :meth:`!C.save`
+would never be found at all. This is bad, because if :class:`!C`'s :meth:`!save`
+method is saving some internal state specific to :class:`!C`, not calling it will
result in that state never getting saved.
New-style classes follow a different algorithm that's a bit more complicated to
@@ -276,22 +276,22 @@ produces more useful results for really complicated inheritance graphs.)
#. List all the base classes, following the classic lookup rule and include a
class multiple times if it's visited repeatedly. In the above example, the list
- of visited classes is [:class:`D`, :class:`B`, :class:`A`, :class:`C`,
- :class:`A`].
+ of visited classes is [:class:`!D`, :class:`!B`, :class:`!A`, :class:`!C`,
+ :class:`!A`].
#. Scan the list for duplicated classes. If any are found, remove all but one
occurrence, leaving the *last* one in the list. In the above example, the list
- becomes [:class:`D`, :class:`B`, :class:`C`, :class:`A`] after dropping
+ becomes [:class:`!D`, :class:`!B`, :class:`!C`, :class:`!A`] after dropping
duplicates.
-Following this rule, referring to :meth:`D.save` will return :meth:`C.save`,
+Following this rule, referring to :meth:`!D.save` will return :meth:`!C.save`,
which is the behaviour we're after. This lookup rule is the same as the one
followed by Common Lisp. A new built-in function, :func:`super`, provides a way
to get at a class's superclasses without having to reimplement Python's
algorithm. The most commonly used form will be ``super(class, obj)``, which
returns a bound superclass object (not the actual class object). This form
will be used in methods to call a method in the superclass; for example,
-:class:`D`'s :meth:`save` method would look like this::
+:class:`!D`'s :meth:`!save` method would look like this::
class D (B,C):
def save (self):
@@ -309,7 +309,7 @@ Attribute Access
----------------
A fair number of sophisticated Python classes define hooks for attribute access
-using :meth:`__getattr__`; most commonly this is done for convenience, to make
+using :meth:`~object.__getattr__`; most commonly this is done for convenience, to make
code more readable by automatically mapping an attribute access such as
``obj.parent`` into a method call such as ``obj.get_parent``. Python 2.2 adds
some new ways of controlling attribute access.
@@ -321,22 +321,22 @@ instance's dictionary.
New-style classes also support a new method,
``__getattribute__(attr_name)``. The difference between the two methods is
-that :meth:`__getattribute__` is *always* called whenever any attribute is
-accessed, while the old :meth:`__getattr__` is only called if ``foo`` isn't
+that :meth:`~object.__getattribute__` is *always* called whenever any attribute is
+accessed, while the old :meth:`~object.__getattr__` is only called if ``foo`` isn't
found in the instance's dictionary.
However, Python 2.2's support for :dfn:`properties` will often be a simpler way
-to trap attribute references. Writing a :meth:`__getattr__` method is
+to trap attribute references. Writing a :meth:`!__getattr__` method is
complicated because to avoid recursion you can't use regular attribute accesses
inside them, and instead have to mess around with the contents of
-:attr:`~object.__dict__`. :meth:`__getattr__` methods also end up being called by Python
-when it checks for other methods such as :meth:`__repr__` or :meth:`__coerce__`,
+:attr:`~object.__dict__`. :meth:`~object.__getattr__` methods also end up being called by Python
+when it checks for other methods such as :meth:`~object.__repr__` or :meth:`!__coerce__`,
and so have to be written with this in mind. Finally, calling a function on
every attribute access results in a sizable performance loss.
:class:`property` is a new built-in type that packages up three functions that
get, set, or delete an attribute, and a docstring. For example, if you want to
-define a :attr:`size` attribute that's computed, but also settable, you could
+define a :attr:`!size` attribute that's computed, but also settable, you could
write::
class C(object):
@@ -355,9 +355,9 @@ write::
"Storage size of this instance")
That is certainly clearer and easier to write than a pair of
-:meth:`__getattr__`/:meth:`__setattr__` methods that check for the :attr:`size`
+:meth:`!__getattr__`/:meth:`!__setattr__` methods that check for the :attr:`!size`
attribute and handle it specially while retrieving all other attributes from the
-instance's :attr:`~object.__dict__`. Accesses to :attr:`size` are also the only ones
+instance's :attr:`~object.__dict__`. Accesses to :attr:`!size` are also the only ones
which have to perform the work of calling a function, so references to other
attributes run at their usual speed.
@@ -447,7 +447,7 @@ an iterator for the object *obj*, while ``iter(C, sentinel)`` returns an
iterator that will invoke the callable object *C* until it returns *sentinel* to
signal that the iterator is done.
-Python classes can define an :meth:`__iter__` method, which should create and
+Python classes can define an :meth:`!__iter__` method, which should create and
return a new iterator for the object; if the object is its own iterator, this
method can just return ``self``. In particular, iterators will usually be their
own iterators. Extension types implemented in C can implement a :c:member:`~PyTypeObject.tp_iter`
@@ -478,7 +478,7 @@ there are no more values to be returned, calling :meth:`next` should raise the
In 2.2, Python's :keyword:`for` statement no longer expects a sequence; it
expects something for which :func:`iter` will return an iterator. For backward
compatibility and convenience, an iterator is automatically constructed for
-sequences that don't implement :meth:`__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so
+sequences that don't implement :meth:`!__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so
``for i in [1,2,3]`` will still work. Wherever the Python interpreter loops
over a sequence, it's been changed to use the iterator protocol. This means you
can do things like this::
@@ -510,8 +510,8 @@ Iterator support has been added to some of Python's basic types. Calling
Oct 10
That's just the default behaviour. If you want to iterate over keys, values, or
-key/value pairs, you can explicitly call the :meth:`iterkeys`,
-:meth:`itervalues`, or :meth:`iteritems` methods to get an appropriate iterator.
+key/value pairs, you can explicitly call the :meth:`!iterkeys`,
+:meth:`!itervalues`, or :meth:`!iteritems` methods to get an appropriate iterator.
In a minor related change, the :keyword:`in` operator now works on dictionaries,
so ``key in dict`` is now equivalent to ``dict.has_key(key)``.
@@ -580,7 +580,7 @@ allowed inside the :keyword:`!try` block of a
:keyword:`try`...\ :keyword:`finally` statement; read :pep:`255` for a full
explanation of the interaction between :keyword:`!yield` and exceptions.)
-Here's a sample usage of the :func:`generate_ints` generator::
+Here's a sample usage of the :func:`!generate_ints` generator::
>>> gen = generate_ints(3)
>>> gen
@@ -641,7 +641,7 @@ like::
sentence := "Store it in the neighboring harbor"
if (i := find("or", sentence)) > 5 then write(i)
-In Icon the :func:`find` function returns the indexes at which the substring
+In Icon the :func:`!find` function returns the indexes at which the substring
"or" is found: 3, 23, 33. In the :keyword:`if` statement, ``i`` is first
assigned a value of 3, but 3 is less than 5, so the comparison fails, and Icon
retries it with the second value of 23. 23 is greater than 5, so the comparison
@@ -671,7 +671,7 @@ PEP 237: Unifying Long Integers and Integers
In recent versions, the distinction between regular integers, which are 32-bit
values on most machines, and long integers, which can be of arbitrary size, was
becoming an annoyance. For example, on platforms that support files larger than
-``2**32`` bytes, the :meth:`tell` method of file objects has to return a long
+``2**32`` bytes, the :meth:`!tell` method of file objects has to return a long
integer. However, there were various bits of Python that expected plain integers
and would raise an error if a long integer was provided instead. For example,
in Python 1.5, only regular integers could be used as a slice index, and
@@ -752,7 +752,7 @@ Here are the changes 2.2 introduces:
0.5. Without the ``__future__`` statement, ``/`` still means classic division.
The default meaning of ``/`` will not change until Python 3.0.
-* Classes can define methods called :meth:`__truediv__` and :meth:`__floordiv__`
+* Classes can define methods called :meth:`~object.__truediv__` and :meth:`~object.__floordiv__`
to overload the two division operators. At the C level, there are also slots in
the :c:type:`PyNumberMethods` structure so extension types can define the two
operators.
@@ -785,17 +785,17 @@ support.)
When built to use UCS-4 (a "wide Python"), the interpreter can natively handle
Unicode characters from U+000000 to U+110000, so the range of legal values for
-the :func:`unichr` function is expanded accordingly. Using an interpreter
+the :func:`!unichr` function is expanded accordingly. Using an interpreter
compiled to use UCS-2 (a "narrow Python"), values greater than 65535 will still
-cause :func:`unichr` to raise a :exc:`ValueError` exception. This is all
+cause :func:`!unichr` to raise a :exc:`ValueError` exception. This is all
described in :pep:`261`, "Support for 'wide' Unicode characters"; consult it for
further details.
Another change is simpler to explain. Since their introduction, Unicode strings
-have supported an :meth:`encode` method to convert the string to a selected
+have supported an :meth:`!encode` method to convert the string to a selected
encoding such as UTF-8 or Latin-1. A symmetric ``decode([*encoding*])``
method has been added to 8-bit strings (though not to Unicode strings) in 2.2.
-:meth:`decode` assumes that the string is in the specified encoding and decodes
+:meth:`!decode` assumes that the string is in the specified encoding and decodes
it, returning whatever is returned by the codec.
Using this new feature, codecs have been added for tasks not directly related to
@@ -819,10 +819,10 @@ encoding, and compression with the :mod:`zlib` module::
>>> "sheesh".encode('rot-13')
'furrfu'
-To convert a class instance to Unicode, a :meth:`__unicode__` method can be
-defined by a class, analogous to :meth:`__str__`.
+To convert a class instance to Unicode, a :meth:`!__unicode__` method can be
+defined by a class, analogous to :meth:`!__str__`.
-:meth:`encode`, :meth:`decode`, and :meth:`__unicode__` were implemented by
+:meth:`!encode`, :meth:`!decode`, and :meth:`!__unicode__` were implemented by
Marc-André Lemburg. The changes to support using UCS-4 internally were
implemented by Fredrik Lundh and Martin von Löwis.
@@ -859,7 +859,7 @@ doesn't work::
return g(value-1) + 1
...
-The function :func:`g` will always raise a :exc:`NameError` exception, because
+The function :func:`!g` will always raise a :exc:`NameError` exception, because
the binding of the name ``g`` isn't in either its local namespace or in the
module-level namespace. This isn't much of a problem in practice (how often do
you recursively define interior functions like this?), but this also made using
@@ -915,7 +915,7 @@ To make the preceding explanation a bit clearer, here's an example::
Line 4 containing the ``exec`` statement is a syntax error, since
``exec`` would define a new local variable named ``x`` whose value should
-be accessed by :func:`g`.
+be accessed by :func:`!g`.
This shouldn't be much of a limitation, since ``exec`` is rarely used in
most Python code (and when it is used, it's often a sign of a poor design
@@ -933,7 +933,7 @@ anyway).
New and Improved Modules
========================
-* The :mod:`xmlrpclib` module was contributed to the standard library by Fredrik
+* The :mod:`!xmlrpclib` module was contributed to the standard library by Fredrik
Lundh, providing support for writing XML-RPC clients. XML-RPC is a simple
remote procedure call protocol built on top of HTTP and XML. For example, the
following snippet retrieves a list of RSS channels from the O'Reilly Network,
@@ -956,7 +956,7 @@ New and Improved Modules
# 'description': 'A utility which converts HTML to XSL FO.',
# 'title': 'html2fo 0.3 (Default)'}, ... ]
- The :mod:`SimpleXMLRPCServer` module makes it easy to create straightforward
+ The :mod:`!SimpleXMLRPCServer` module makes it easy to create straightforward
XML-RPC servers. See http://xmlrpc.scripting.com/ for more information about XML-RPC.
* The new :mod:`hmac` module implements the HMAC algorithm described by
@@ -964,9 +964,9 @@ New and Improved Modules
* Several functions that originally returned lengthy tuples now return
pseudo-sequences that still behave like tuples but also have mnemonic attributes such
- as memberst_mtime or :attr:`tm_year`. The enhanced functions include
- :func:`stat`, :func:`fstat`, :func:`statvfs`, and :func:`fstatvfs` in the
- :mod:`os` module, and :func:`localtime`, :func:`gmtime`, and :func:`strptime` in
+ as :attr:`!memberst_mtime` or :attr:`!tm_year`. The enhanced functions include
+ :func:`~os.stat`, :func:`~os.fstat`, :func:`~os.statvfs`, and :func:`~os.fstatvfs` in the
+ :mod:`os` module, and :func:`~time.localtime`, :func:`~time.gmtime`, and :func:`~time.strptime` in
the :mod:`time` module.
For example, to obtain a file's size using the old tuples, you'd end up writing
@@ -999,7 +999,7 @@ New and Improved Modules
underlying the :mod:`re` module. For example, the :func:`re.sub` and
:func:`re.split` functions have been rewritten in C. Another contributed patch
speeds up certain Unicode character ranges by a factor of two, and a new
- :meth:`finditer` method that returns an iterator over all the non-overlapping
+ :meth:`~re.finditer` method that returns an iterator over all the non-overlapping
matches in a given string. (SRE is maintained by Fredrik Lundh. The
BIGCHARSET patch was contributed by Martin von Löwis.)
@@ -1012,33 +1012,33 @@ New and Improved Modules
new extensions: the NAMESPACE extension defined in :rfc:`2342`, SORT, GETACL and
SETACL. (Contributed by Anthony Baxter and Michel Pelletier.)
-* The :mod:`rfc822` module's parsing of email addresses is now compliant with
+* The :mod:`!rfc822` module's parsing of email addresses is now compliant with
:rfc:`2822`, an update to :rfc:`822`. (The module's name is *not* going to be
changed to ``rfc2822``.) A new package, :mod:`email`, has also been added for
parsing and generating e-mail messages. (Contributed by Barry Warsaw, and
arising out of his work on Mailman.)
-* The :mod:`difflib` module now contains a new :class:`Differ` class for
+* The :mod:`difflib` module now contains a new :class:`!Differ` class for
producing human-readable lists of changes (a "delta") between two sequences of
- lines of text. There are also two generator functions, :func:`ndiff` and
- :func:`restore`, which respectively return a delta from two sequences, or one of
+ lines of text. There are also two generator functions, :func:`!ndiff` and
+ :func:`!restore`, which respectively return a delta from two sequences, or one of
the original sequences from a delta. (Grunt work contributed by David Goodger,
from ndiff.py code by Tim Peters who then did the generatorization.)
-* New constants :const:`ascii_letters`, :const:`ascii_lowercase`, and
- :const:`ascii_uppercase` were added to the :mod:`string` module. There were
- several modules in the standard library that used :const:`string.letters` to
+* New constants :const:`!ascii_letters`, :const:`!ascii_lowercase`, and
+ :const:`!ascii_uppercase` were added to the :mod:`string` module. There were
+ several modules in the standard library that used :const:`!string.letters` to
mean the ranges A-Za-z, but that assumption is incorrect when locales are in
- use, because :const:`string.letters` varies depending on the set of legal
+ use, because :const:`!string.letters` varies depending on the set of legal
characters defined by the current locale. The buggy modules have all been fixed
- to use :const:`ascii_letters` instead. (Reported by an unknown person; fixed by
+ to use :const:`!ascii_letters` instead. (Reported by an unknown person; fixed by
Fred L. Drake, Jr.)
* The :mod:`mimetypes` module now makes it easier to use alternative MIME-type
- databases by the addition of a :class:`MimeTypes` class, which takes a list of
+ databases by the addition of a :class:`~mimetypes.MimeTypes` class, which takes a list of
filenames to be parsed. (Contributed by Fred L. Drake, Jr.)
-* A :class:`Timer` class was added to the :mod:`threading` module that allows
+* A :class:`~threading.Timer` class was added to the :mod:`threading` module that allows
scheduling an activity to happen at some future time. (Contributed by Itamar
Shtull-Trauring.)
@@ -1114,7 +1114,7 @@ code, none of the changes described here will affect you very much.
* Two new wrapper functions, :c:func:`PyOS_snprintf` and :c:func:`PyOS_vsnprintf`
were added to provide cross-platform implementations for the relatively new
:c:func:`snprintf` and :c:func:`vsnprintf` C lib APIs. In contrast to the standard
- :c:func:`sprintf` and :c:func:`vsprintf` functions, the Python versions check the
+ :c:func:`sprintf` and :c:func:`!vsprintf` functions, the Python versions check the
bounds of the buffer used to protect against buffer overruns. (Contributed by
M.-A. Lemburg.)
@@ -1212,12 +1212,12 @@ Some of the more notable changes are:
* The :file:`Tools/scripts/ftpmirror.py` script now parses a :file:`.netrc`
file, if you have one. (Contributed by Mike Romberg.)
-* Some features of the object returned by the :func:`xrange` function are now
+* Some features of the object returned by the :func:`!xrange` function are now
deprecated, and trigger warnings when they're accessed; they'll disappear in
- Python 2.3. :class:`xrange` objects tried to pretend they were full sequence
+ Python 2.3. :class:`!xrange` objects tried to pretend they were full sequence
types by supporting slicing, sequence multiplication, and the :keyword:`in`
operator, but these features were rarely used and therefore buggy. The
- :meth:`tolist` method and the :attr:`start`, :attr:`stop`, and :attr:`step`
+ :meth:`!tolist` method and the :attr:`!start`, :attr:`!stop`, and :attr:`!step`
attributes are also being deprecated. At the C level, the fourth argument to
the :c:func:`!PyRange_New` function, ``repeat``, has also been deprecated.
1
0
![](https://secure.gravatar.com/avatar/cc7737cd64a84f1b5c61a160798e97ee.jpg?s=120&d=mm&r=g)
[3.12] gh-101100: Fix Sphinx warnings in `whatsnew/2.2.rst` (GH-112366) (#114711)
by hugovk 29 Jan '24
by hugovk 29 Jan '24
29 Jan '24
https://github.com/python/cpython/commit/c09a01032df9a121d525838141e3fed203…
commit: c09a01032df9a121d525838141e3fed203735404
branch: 3.12
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: hugovk <1324225+hugovk(a)users.noreply.github.com>
date: 2024-01-29T13:18:34Z
summary:
[3.12] gh-101100: Fix Sphinx warnings in `whatsnew/2.2.rst` (GH-112366) (#114711)
Co-authored-by: Hugo van Kemenade <1324225+hugovk(a)users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <hugovk(a)users.noreply.github.com>
files:
M Doc/tools/.nitignore
M Doc/whatsnew/2.2.rst
diff --git a/Doc/tools/.nitignore b/Doc/tools/.nitignore
index 9edbdf18d9a24a..e520359e12ebe6 100644
--- a/Doc/tools/.nitignore
+++ b/Doc/tools/.nitignore
@@ -109,7 +109,6 @@ Doc/tutorial/datastructures.rst
Doc/using/windows.rst
Doc/whatsnew/2.0.rst
Doc/whatsnew/2.1.rst
-Doc/whatsnew/2.2.rst
Doc/whatsnew/2.4.rst
Doc/whatsnew/2.5.rst
Doc/whatsnew/2.6.rst
diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index 6efc23a82de923..968bd7a126bdf0 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -53,9 +53,9 @@ A long time ago I wrote a web page listing flaws in Python's design. One of the
most significant flaws was that it's impossible to subclass Python types
implemented in C. In particular, it's not possible to subclass built-in types,
so you can't just subclass, say, lists in order to add a single useful method to
-them. The :mod:`UserList` module provides a class that supports all of the
+them. The :mod:`!UserList` module provides a class that supports all of the
methods of lists and that can be subclassed further, but there's lots of C code
-that expects a regular Python list and won't accept a :class:`UserList`
+that expects a regular Python list and won't accept a :class:`!UserList`
instance.
Python 2.2 fixes this, and in the process adds some exciting new capabilities.
@@ -69,7 +69,7 @@ A brief summary:
* It's also possible to automatically call methods on accessing or setting an
instance attribute by using a new mechanism called :dfn:`properties`. Many uses
- of :meth:`__getattr__` can be rewritten to use properties instead, making the
+ of :meth:`!__getattr__` can be rewritten to use properties instead, making the
resulting code simpler and faster. As a small side benefit, attributes can now
have docstrings, too.
@@ -120,7 +120,7 @@ added so if no built-in type is suitable, you can just subclass
This means that :keyword:`class` statements that don't have any base classes are
always classic classes in Python 2.2. (Actually you can also change this by
-setting a module-level variable named :attr:`__metaclass__` --- see :pep:`253`
+setting a module-level variable named :attr:`!__metaclass__` --- see :pep:`253`
for the details --- but it's easier to just subclass :class:`object`.)
The type objects for the built-in types are available as built-ins, named using
@@ -134,8 +134,8 @@ type objects that behave as factories when called. ::
123
To make the set of types complete, new type objects such as :func:`dict` and
-:func:`file` have been added. Here's a more interesting example, adding a
-:meth:`lock` method to file objects::
+:func:`!file` have been added. Here's a more interesting example, adding a
+:meth:`!lock` method to file objects::
class LockableFile(file):
def lock (self, operation, length=0, start=0, whence=0):
@@ -146,7 +146,7 @@ To make the set of types complete, new type objects such as :func:`dict` and
The now-obsolete :mod:`!posixfile` module contained a class that emulated all of
a file object's methods and also added a :meth:`!lock` method, but this class
couldn't be passed to internal functions that expected a built-in file,
-something which is possible with our new :class:`LockableFile`.
+something which is possible with our new :class:`!LockableFile`.
Descriptors
@@ -154,11 +154,11 @@ Descriptors
In previous versions of Python, there was no consistent way to discover what
attributes and methods were supported by an object. There were some informal
-conventions, such as defining :attr:`__members__` and :attr:`__methods__`
+conventions, such as defining :attr:`!__members__` and :attr:`!__methods__`
attributes that were lists of names, but often the author of an extension type
or a class wouldn't bother to define them. You could fall back on inspecting
the :attr:`~object.__dict__` of an object, but when class inheritance or an arbitrary
-:meth:`__getattr__` hook were in use this could still be inaccurate.
+:meth:`!__getattr__` hook were in use this could still be inaccurate.
The one big idea underlying the new class model is that an API for describing
the attributes of an object using :dfn:`descriptors` has been formalized.
@@ -171,7 +171,7 @@ attributes of their own:
* :attr:`~definition.__name__` is the attribute's name.
-* :attr:`__doc__` is the attribute's docstring.
+* :attr:`!__doc__` is the attribute's docstring.
* ``__get__(object)`` is a method that retrieves the attribute value from
*object*.
@@ -186,7 +186,7 @@ are::
descriptor = obj.__class__.x
descriptor.__get__(obj)
-For methods, :meth:`descriptor.__get__` returns a temporary object that's
+For methods, :meth:`!descriptor.__get__` returns a temporary object that's
callable, and wraps up the instance and the method to be called on it. This is
also why static methods and class methods are now possible; they have
descriptors that wrap up just the method, or the method and the class. As a
@@ -204,7 +204,7 @@ methods are defined like this::
...
g = classmethod(g)
-The :func:`staticmethod` function takes the function :func:`f`, and returns it
+The :func:`staticmethod` function takes the function :func:`!f`, and returns it
wrapped up in a descriptor so it can be stored in the class object. You might
expect there to be special syntax for creating such methods (``def static f``,
``defstatic f()``, or something like that) but no such syntax has been defined
@@ -232,10 +232,10 @@ like this::
f = eiffelmethod(f, pre_f, post_f)
-Note that a person using the new :func:`eiffelmethod` doesn't have to understand
+Note that a person using the new :func:`!eiffelmethod` doesn't have to understand
anything about descriptors. This is why I think the new features don't increase
the basic complexity of the language. There will be a few wizards who need to
-know about it in order to write :func:`eiffelmethod` or the ZODB or whatever,
+know about it in order to write :func:`!eiffelmethod` or the ZODB or whatever,
but most users will just write code on top of the resulting libraries and ignore
the implementation details.
@@ -263,10 +263,10 @@ from :pep:`253` by Guido van Rossum)::
The lookup rule for classic classes is simple but not very smart; the base
classes are searched depth-first, going from left to right. A reference to
-:meth:`D.save` will search the classes :class:`D`, :class:`B`, and then
-:class:`A`, where :meth:`save` would be found and returned. :meth:`C.save`
-would never be found at all. This is bad, because if :class:`C`'s :meth:`save`
-method is saving some internal state specific to :class:`C`, not calling it will
+:meth:`!D.save` will search the classes :class:`!D`, :class:`!B`, and then
+:class:`!A`, where :meth:`!save` would be found and returned. :meth:`!C.save`
+would never be found at all. This is bad, because if :class:`!C`'s :meth:`!save`
+method is saving some internal state specific to :class:`!C`, not calling it will
result in that state never getting saved.
New-style classes follow a different algorithm that's a bit more complicated to
@@ -276,22 +276,22 @@ produces more useful results for really complicated inheritance graphs.)
#. List all the base classes, following the classic lookup rule and include a
class multiple times if it's visited repeatedly. In the above example, the list
- of visited classes is [:class:`D`, :class:`B`, :class:`A`, :class:`C`,
- :class:`A`].
+ of visited classes is [:class:`!D`, :class:`!B`, :class:`!A`, :class:`!C`,
+ :class:`!A`].
#. Scan the list for duplicated classes. If any are found, remove all but one
occurrence, leaving the *last* one in the list. In the above example, the list
- becomes [:class:`D`, :class:`B`, :class:`C`, :class:`A`] after dropping
+ becomes [:class:`!D`, :class:`!B`, :class:`!C`, :class:`!A`] after dropping
duplicates.
-Following this rule, referring to :meth:`D.save` will return :meth:`C.save`,
+Following this rule, referring to :meth:`!D.save` will return :meth:`!C.save`,
which is the behaviour we're after. This lookup rule is the same as the one
followed by Common Lisp. A new built-in function, :func:`super`, provides a way
to get at a class's superclasses without having to reimplement Python's
algorithm. The most commonly used form will be ``super(class, obj)``, which
returns a bound superclass object (not the actual class object). This form
will be used in methods to call a method in the superclass; for example,
-:class:`D`'s :meth:`save` method would look like this::
+:class:`!D`'s :meth:`!save` method would look like this::
class D (B,C):
def save (self):
@@ -309,7 +309,7 @@ Attribute Access
----------------
A fair number of sophisticated Python classes define hooks for attribute access
-using :meth:`__getattr__`; most commonly this is done for convenience, to make
+using :meth:`~object.__getattr__`; most commonly this is done for convenience, to make
code more readable by automatically mapping an attribute access such as
``obj.parent`` into a method call such as ``obj.get_parent``. Python 2.2 adds
some new ways of controlling attribute access.
@@ -321,22 +321,22 @@ instance's dictionary.
New-style classes also support a new method,
``__getattribute__(attr_name)``. The difference between the two methods is
-that :meth:`__getattribute__` is *always* called whenever any attribute is
-accessed, while the old :meth:`__getattr__` is only called if ``foo`` isn't
+that :meth:`~object.__getattribute__` is *always* called whenever any attribute is
+accessed, while the old :meth:`~object.__getattr__` is only called if ``foo`` isn't
found in the instance's dictionary.
However, Python 2.2's support for :dfn:`properties` will often be a simpler way
-to trap attribute references. Writing a :meth:`__getattr__` method is
+to trap attribute references. Writing a :meth:`!__getattr__` method is
complicated because to avoid recursion you can't use regular attribute accesses
inside them, and instead have to mess around with the contents of
-:attr:`~object.__dict__`. :meth:`__getattr__` methods also end up being called by Python
-when it checks for other methods such as :meth:`__repr__` or :meth:`__coerce__`,
+:attr:`~object.__dict__`. :meth:`~object.__getattr__` methods also end up being called by Python
+when it checks for other methods such as :meth:`~object.__repr__` or :meth:`!__coerce__`,
and so have to be written with this in mind. Finally, calling a function on
every attribute access results in a sizable performance loss.
:class:`property` is a new built-in type that packages up three functions that
get, set, or delete an attribute, and a docstring. For example, if you want to
-define a :attr:`size` attribute that's computed, but also settable, you could
+define a :attr:`!size` attribute that's computed, but also settable, you could
write::
class C(object):
@@ -355,9 +355,9 @@ write::
"Storage size of this instance")
That is certainly clearer and easier to write than a pair of
-:meth:`__getattr__`/:meth:`__setattr__` methods that check for the :attr:`size`
+:meth:`!__getattr__`/:meth:`!__setattr__` methods that check for the :attr:`!size`
attribute and handle it specially while retrieving all other attributes from the
-instance's :attr:`~object.__dict__`. Accesses to :attr:`size` are also the only ones
+instance's :attr:`~object.__dict__`. Accesses to :attr:`!size` are also the only ones
which have to perform the work of calling a function, so references to other
attributes run at their usual speed.
@@ -447,7 +447,7 @@ an iterator for the object *obj*, while ``iter(C, sentinel)`` returns an
iterator that will invoke the callable object *C* until it returns *sentinel* to
signal that the iterator is done.
-Python classes can define an :meth:`__iter__` method, which should create and
+Python classes can define an :meth:`!__iter__` method, which should create and
return a new iterator for the object; if the object is its own iterator, this
method can just return ``self``. In particular, iterators will usually be their
own iterators. Extension types implemented in C can implement a :c:member:`~PyTypeObject.tp_iter`
@@ -478,7 +478,7 @@ there are no more values to be returned, calling :meth:`next` should raise the
In 2.2, Python's :keyword:`for` statement no longer expects a sequence; it
expects something for which :func:`iter` will return an iterator. For backward
compatibility and convenience, an iterator is automatically constructed for
-sequences that don't implement :meth:`__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so
+sequences that don't implement :meth:`!__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so
``for i in [1,2,3]`` will still work. Wherever the Python interpreter loops
over a sequence, it's been changed to use the iterator protocol. This means you
can do things like this::
@@ -510,8 +510,8 @@ Iterator support has been added to some of Python's basic types. Calling
Oct 10
That's just the default behaviour. If you want to iterate over keys, values, or
-key/value pairs, you can explicitly call the :meth:`iterkeys`,
-:meth:`itervalues`, or :meth:`iteritems` methods to get an appropriate iterator.
+key/value pairs, you can explicitly call the :meth:`!iterkeys`,
+:meth:`!itervalues`, or :meth:`!iteritems` methods to get an appropriate iterator.
In a minor related change, the :keyword:`in` operator now works on dictionaries,
so ``key in dict`` is now equivalent to ``dict.has_key(key)``.
@@ -580,7 +580,7 @@ allowed inside the :keyword:`!try` block of a
:keyword:`try`...\ :keyword:`finally` statement; read :pep:`255` for a full
explanation of the interaction between :keyword:`!yield` and exceptions.)
-Here's a sample usage of the :func:`generate_ints` generator::
+Here's a sample usage of the :func:`!generate_ints` generator::
>>> gen = generate_ints(3)
>>> gen
@@ -641,7 +641,7 @@ like::
sentence := "Store it in the neighboring harbor"
if (i := find("or", sentence)) > 5 then write(i)
-In Icon the :func:`find` function returns the indexes at which the substring
+In Icon the :func:`!find` function returns the indexes at which the substring
"or" is found: 3, 23, 33. In the :keyword:`if` statement, ``i`` is first
assigned a value of 3, but 3 is less than 5, so the comparison fails, and Icon
retries it with the second value of 23. 23 is greater than 5, so the comparison
@@ -671,7 +671,7 @@ PEP 237: Unifying Long Integers and Integers
In recent versions, the distinction between regular integers, which are 32-bit
values on most machines, and long integers, which can be of arbitrary size, was
becoming an annoyance. For example, on platforms that support files larger than
-``2**32`` bytes, the :meth:`tell` method of file objects has to return a long
+``2**32`` bytes, the :meth:`!tell` method of file objects has to return a long
integer. However, there were various bits of Python that expected plain integers
and would raise an error if a long integer was provided instead. For example,
in Python 1.5, only regular integers could be used as a slice index, and
@@ -752,7 +752,7 @@ Here are the changes 2.2 introduces:
0.5. Without the ``__future__`` statement, ``/`` still means classic division.
The default meaning of ``/`` will not change until Python 3.0.
-* Classes can define methods called :meth:`__truediv__` and :meth:`__floordiv__`
+* Classes can define methods called :meth:`~object.__truediv__` and :meth:`~object.__floordiv__`
to overload the two division operators. At the C level, there are also slots in
the :c:type:`PyNumberMethods` structure so extension types can define the two
operators.
@@ -785,17 +785,17 @@ support.)
When built to use UCS-4 (a "wide Python"), the interpreter can natively handle
Unicode characters from U+000000 to U+110000, so the range of legal values for
-the :func:`unichr` function is expanded accordingly. Using an interpreter
+the :func:`!unichr` function is expanded accordingly. Using an interpreter
compiled to use UCS-2 (a "narrow Python"), values greater than 65535 will still
-cause :func:`unichr` to raise a :exc:`ValueError` exception. This is all
+cause :func:`!unichr` to raise a :exc:`ValueError` exception. This is all
described in :pep:`261`, "Support for 'wide' Unicode characters"; consult it for
further details.
Another change is simpler to explain. Since their introduction, Unicode strings
-have supported an :meth:`encode` method to convert the string to a selected
+have supported an :meth:`!encode` method to convert the string to a selected
encoding such as UTF-8 or Latin-1. A symmetric ``decode([*encoding*])``
method has been added to 8-bit strings (though not to Unicode strings) in 2.2.
-:meth:`decode` assumes that the string is in the specified encoding and decodes
+:meth:`!decode` assumes that the string is in the specified encoding and decodes
it, returning whatever is returned by the codec.
Using this new feature, codecs have been added for tasks not directly related to
@@ -819,10 +819,10 @@ encoding, and compression with the :mod:`zlib` module::
>>> "sheesh".encode('rot-13')
'furrfu'
-To convert a class instance to Unicode, a :meth:`__unicode__` method can be
-defined by a class, analogous to :meth:`__str__`.
+To convert a class instance to Unicode, a :meth:`!__unicode__` method can be
+defined by a class, analogous to :meth:`!__str__`.
-:meth:`encode`, :meth:`decode`, and :meth:`__unicode__` were implemented by
+:meth:`!encode`, :meth:`!decode`, and :meth:`!__unicode__` were implemented by
Marc-André Lemburg. The changes to support using UCS-4 internally were
implemented by Fredrik Lundh and Martin von Löwis.
@@ -859,7 +859,7 @@ doesn't work::
return g(value-1) + 1
...
-The function :func:`g` will always raise a :exc:`NameError` exception, because
+The function :func:`!g` will always raise a :exc:`NameError` exception, because
the binding of the name ``g`` isn't in either its local namespace or in the
module-level namespace. This isn't much of a problem in practice (how often do
you recursively define interior functions like this?), but this also made using
@@ -915,7 +915,7 @@ To make the preceding explanation a bit clearer, here's an example::
Line 4 containing the ``exec`` statement is a syntax error, since
``exec`` would define a new local variable named ``x`` whose value should
-be accessed by :func:`g`.
+be accessed by :func:`!g`.
This shouldn't be much of a limitation, since ``exec`` is rarely used in
most Python code (and when it is used, it's often a sign of a poor design
@@ -933,7 +933,7 @@ anyway).
New and Improved Modules
========================
-* The :mod:`xmlrpclib` module was contributed to the standard library by Fredrik
+* The :mod:`!xmlrpclib` module was contributed to the standard library by Fredrik
Lundh, providing support for writing XML-RPC clients. XML-RPC is a simple
remote procedure call protocol built on top of HTTP and XML. For example, the
following snippet retrieves a list of RSS channels from the O'Reilly Network,
@@ -956,7 +956,7 @@ New and Improved Modules
# 'description': 'A utility which converts HTML to XSL FO.',
# 'title': 'html2fo 0.3 (Default)'}, ... ]
- The :mod:`SimpleXMLRPCServer` module makes it easy to create straightforward
+ The :mod:`!SimpleXMLRPCServer` module makes it easy to create straightforward
XML-RPC servers. See http://xmlrpc.scripting.com/ for more information about XML-RPC.
* The new :mod:`hmac` module implements the HMAC algorithm described by
@@ -964,9 +964,9 @@ New and Improved Modules
* Several functions that originally returned lengthy tuples now return
pseudo-sequences that still behave like tuples but also have mnemonic attributes such
- as memberst_mtime or :attr:`tm_year`. The enhanced functions include
- :func:`stat`, :func:`fstat`, :func:`statvfs`, and :func:`fstatvfs` in the
- :mod:`os` module, and :func:`localtime`, :func:`gmtime`, and :func:`strptime` in
+ as :attr:`!memberst_mtime` or :attr:`!tm_year`. The enhanced functions include
+ :func:`~os.stat`, :func:`~os.fstat`, :func:`~os.statvfs`, and :func:`~os.fstatvfs` in the
+ :mod:`os` module, and :func:`~time.localtime`, :func:`~time.gmtime`, and :func:`~time.strptime` in
the :mod:`time` module.
For example, to obtain a file's size using the old tuples, you'd end up writing
@@ -999,7 +999,7 @@ New and Improved Modules
underlying the :mod:`re` module. For example, the :func:`re.sub` and
:func:`re.split` functions have been rewritten in C. Another contributed patch
speeds up certain Unicode character ranges by a factor of two, and a new
- :meth:`finditer` method that returns an iterator over all the non-overlapping
+ :meth:`~re.finditer` method that returns an iterator over all the non-overlapping
matches in a given string. (SRE is maintained by Fredrik Lundh. The
BIGCHARSET patch was contributed by Martin von Löwis.)
@@ -1012,33 +1012,33 @@ New and Improved Modules
new extensions: the NAMESPACE extension defined in :rfc:`2342`, SORT, GETACL and
SETACL. (Contributed by Anthony Baxter and Michel Pelletier.)
-* The :mod:`rfc822` module's parsing of email addresses is now compliant with
+* The :mod:`!rfc822` module's parsing of email addresses is now compliant with
:rfc:`2822`, an update to :rfc:`822`. (The module's name is *not* going to be
changed to ``rfc2822``.) A new package, :mod:`email`, has also been added for
parsing and generating e-mail messages. (Contributed by Barry Warsaw, and
arising out of his work on Mailman.)
-* The :mod:`difflib` module now contains a new :class:`Differ` class for
+* The :mod:`difflib` module now contains a new :class:`!Differ` class for
producing human-readable lists of changes (a "delta") between two sequences of
- lines of text. There are also two generator functions, :func:`ndiff` and
- :func:`restore`, which respectively return a delta from two sequences, or one of
+ lines of text. There are also two generator functions, :func:`!ndiff` and
+ :func:`!restore`, which respectively return a delta from two sequences, or one of
the original sequences from a delta. (Grunt work contributed by David Goodger,
from ndiff.py code by Tim Peters who then did the generatorization.)
-* New constants :const:`ascii_letters`, :const:`ascii_lowercase`, and
- :const:`ascii_uppercase` were added to the :mod:`string` module. There were
- several modules in the standard library that used :const:`string.letters` to
+* New constants :const:`!ascii_letters`, :const:`!ascii_lowercase`, and
+ :const:`!ascii_uppercase` were added to the :mod:`string` module. There were
+ several modules in the standard library that used :const:`!string.letters` to
mean the ranges A-Za-z, but that assumption is incorrect when locales are in
- use, because :const:`string.letters` varies depending on the set of legal
+ use, because :const:`!string.letters` varies depending on the set of legal
characters defined by the current locale. The buggy modules have all been fixed
- to use :const:`ascii_letters` instead. (Reported by an unknown person; fixed by
+ to use :const:`!ascii_letters` instead. (Reported by an unknown person; fixed by
Fred L. Drake, Jr.)
* The :mod:`mimetypes` module now makes it easier to use alternative MIME-type
- databases by the addition of a :class:`MimeTypes` class, which takes a list of
+ databases by the addition of a :class:`~mimetypes.MimeTypes` class, which takes a list of
filenames to be parsed. (Contributed by Fred L. Drake, Jr.)
-* A :class:`Timer` class was added to the :mod:`threading` module that allows
+* A :class:`~threading.Timer` class was added to the :mod:`threading` module that allows
scheduling an activity to happen at some future time. (Contributed by Itamar
Shtull-Trauring.)
@@ -1114,7 +1114,7 @@ code, none of the changes described here will affect you very much.
* Two new wrapper functions, :c:func:`PyOS_snprintf` and :c:func:`PyOS_vsnprintf`
were added to provide cross-platform implementations for the relatively new
:c:func:`snprintf` and :c:func:`vsnprintf` C lib APIs. In contrast to the standard
- :c:func:`sprintf` and :c:func:`vsprintf` functions, the Python versions check the
+ :c:func:`sprintf` and :c:func:`!vsprintf` functions, the Python versions check the
bounds of the buffer used to protect against buffer overruns. (Contributed by
M.-A. Lemburg.)
@@ -1212,12 +1212,12 @@ Some of the more notable changes are:
* The :file:`Tools/scripts/ftpmirror.py` script now parses a :file:`.netrc`
file, if you have one. (Contributed by Mike Romberg.)
-* Some features of the object returned by the :func:`xrange` function are now
+* Some features of the object returned by the :func:`!xrange` function are now
deprecated, and trigger warnings when they're accessed; they'll disappear in
- Python 2.3. :class:`xrange` objects tried to pretend they were full sequence
+ Python 2.3. :class:`!xrange` objects tried to pretend they were full sequence
types by supporting slicing, sequence multiplication, and the :keyword:`in`
operator, but these features were rarely used and therefore buggy. The
- :meth:`tolist` method and the :attr:`start`, :attr:`stop`, and :attr:`step`
+ :meth:`!tolist` method and the :attr:`!start`, :attr:`!stop`, and :attr:`!step`
attributes are also being deprecated. At the C level, the fourth argument to
the :c:func:`!PyRange_New` function, ``repeat``, has also been deprecated.
1
0
https://github.com/python/cpython/commit/b7a12ab2146f946ae57e2d8019372cafe9…
commit: b7a12ab2146f946ae57e2d8019372cafe94d8375
branch: main
author: Hugo van Kemenade <1324225+hugovk(a)users.noreply.github.com>
committer: hugovk <1324225+hugovk(a)users.noreply.github.com>
date: 2024-01-29T13:12:19Z
summary:
gh-101100: Fix Sphinx warnings in `whatsnew/2.2.rst` (#112366)
Co-authored-by: Hugo van Kemenade <hugovk(a)users.noreply.github.com>
files:
M Doc/tools/.nitignore
M Doc/whatsnew/2.2.rst
diff --git a/Doc/tools/.nitignore b/Doc/tools/.nitignore
index b8b7c2299ca9f4..763503205e1670 100644
--- a/Doc/tools/.nitignore
+++ b/Doc/tools/.nitignore
@@ -90,7 +90,6 @@ Doc/tutorial/datastructures.rst
Doc/using/windows.rst
Doc/whatsnew/2.0.rst
Doc/whatsnew/2.1.rst
-Doc/whatsnew/2.2.rst
Doc/whatsnew/2.4.rst
Doc/whatsnew/2.5.rst
Doc/whatsnew/2.6.rst
diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index 6efc23a82de923..968bd7a126bdf0 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -53,9 +53,9 @@ A long time ago I wrote a web page listing flaws in Python's design. One of the
most significant flaws was that it's impossible to subclass Python types
implemented in C. In particular, it's not possible to subclass built-in types,
so you can't just subclass, say, lists in order to add a single useful method to
-them. The :mod:`UserList` module provides a class that supports all of the
+them. The :mod:`!UserList` module provides a class that supports all of the
methods of lists and that can be subclassed further, but there's lots of C code
-that expects a regular Python list and won't accept a :class:`UserList`
+that expects a regular Python list and won't accept a :class:`!UserList`
instance.
Python 2.2 fixes this, and in the process adds some exciting new capabilities.
@@ -69,7 +69,7 @@ A brief summary:
* It's also possible to automatically call methods on accessing or setting an
instance attribute by using a new mechanism called :dfn:`properties`. Many uses
- of :meth:`__getattr__` can be rewritten to use properties instead, making the
+ of :meth:`!__getattr__` can be rewritten to use properties instead, making the
resulting code simpler and faster. As a small side benefit, attributes can now
have docstrings, too.
@@ -120,7 +120,7 @@ added so if no built-in type is suitable, you can just subclass
This means that :keyword:`class` statements that don't have any base classes are
always classic classes in Python 2.2. (Actually you can also change this by
-setting a module-level variable named :attr:`__metaclass__` --- see :pep:`253`
+setting a module-level variable named :attr:`!__metaclass__` --- see :pep:`253`
for the details --- but it's easier to just subclass :class:`object`.)
The type objects for the built-in types are available as built-ins, named using
@@ -134,8 +134,8 @@ type objects that behave as factories when called. ::
123
To make the set of types complete, new type objects such as :func:`dict` and
-:func:`file` have been added. Here's a more interesting example, adding a
-:meth:`lock` method to file objects::
+:func:`!file` have been added. Here's a more interesting example, adding a
+:meth:`!lock` method to file objects::
class LockableFile(file):
def lock (self, operation, length=0, start=0, whence=0):
@@ -146,7 +146,7 @@ To make the set of types complete, new type objects such as :func:`dict` and
The now-obsolete :mod:`!posixfile` module contained a class that emulated all of
a file object's methods and also added a :meth:`!lock` method, but this class
couldn't be passed to internal functions that expected a built-in file,
-something which is possible with our new :class:`LockableFile`.
+something which is possible with our new :class:`!LockableFile`.
Descriptors
@@ -154,11 +154,11 @@ Descriptors
In previous versions of Python, there was no consistent way to discover what
attributes and methods were supported by an object. There were some informal
-conventions, such as defining :attr:`__members__` and :attr:`__methods__`
+conventions, such as defining :attr:`!__members__` and :attr:`!__methods__`
attributes that were lists of names, but often the author of an extension type
or a class wouldn't bother to define them. You could fall back on inspecting
the :attr:`~object.__dict__` of an object, but when class inheritance or an arbitrary
-:meth:`__getattr__` hook were in use this could still be inaccurate.
+:meth:`!__getattr__` hook were in use this could still be inaccurate.
The one big idea underlying the new class model is that an API for describing
the attributes of an object using :dfn:`descriptors` has been formalized.
@@ -171,7 +171,7 @@ attributes of their own:
* :attr:`~definition.__name__` is the attribute's name.
-* :attr:`__doc__` is the attribute's docstring.
+* :attr:`!__doc__` is the attribute's docstring.
* ``__get__(object)`` is a method that retrieves the attribute value from
*object*.
@@ -186,7 +186,7 @@ are::
descriptor = obj.__class__.x
descriptor.__get__(obj)
-For methods, :meth:`descriptor.__get__` returns a temporary object that's
+For methods, :meth:`!descriptor.__get__` returns a temporary object that's
callable, and wraps up the instance and the method to be called on it. This is
also why static methods and class methods are now possible; they have
descriptors that wrap up just the method, or the method and the class. As a
@@ -204,7 +204,7 @@ methods are defined like this::
...
g = classmethod(g)
-The :func:`staticmethod` function takes the function :func:`f`, and returns it
+The :func:`staticmethod` function takes the function :func:`!f`, and returns it
wrapped up in a descriptor so it can be stored in the class object. You might
expect there to be special syntax for creating such methods (``def static f``,
``defstatic f()``, or something like that) but no such syntax has been defined
@@ -232,10 +232,10 @@ like this::
f = eiffelmethod(f, pre_f, post_f)
-Note that a person using the new :func:`eiffelmethod` doesn't have to understand
+Note that a person using the new :func:`!eiffelmethod` doesn't have to understand
anything about descriptors. This is why I think the new features don't increase
the basic complexity of the language. There will be a few wizards who need to
-know about it in order to write :func:`eiffelmethod` or the ZODB or whatever,
+know about it in order to write :func:`!eiffelmethod` or the ZODB or whatever,
but most users will just write code on top of the resulting libraries and ignore
the implementation details.
@@ -263,10 +263,10 @@ from :pep:`253` by Guido van Rossum)::
The lookup rule for classic classes is simple but not very smart; the base
classes are searched depth-first, going from left to right. A reference to
-:meth:`D.save` will search the classes :class:`D`, :class:`B`, and then
-:class:`A`, where :meth:`save` would be found and returned. :meth:`C.save`
-would never be found at all. This is bad, because if :class:`C`'s :meth:`save`
-method is saving some internal state specific to :class:`C`, not calling it will
+:meth:`!D.save` will search the classes :class:`!D`, :class:`!B`, and then
+:class:`!A`, where :meth:`!save` would be found and returned. :meth:`!C.save`
+would never be found at all. This is bad, because if :class:`!C`'s :meth:`!save`
+method is saving some internal state specific to :class:`!C`, not calling it will
result in that state never getting saved.
New-style classes follow a different algorithm that's a bit more complicated to
@@ -276,22 +276,22 @@ produces more useful results for really complicated inheritance graphs.)
#. List all the base classes, following the classic lookup rule and include a
class multiple times if it's visited repeatedly. In the above example, the list
- of visited classes is [:class:`D`, :class:`B`, :class:`A`, :class:`C`,
- :class:`A`].
+ of visited classes is [:class:`!D`, :class:`!B`, :class:`!A`, :class:`!C`,
+ :class:`!A`].
#. Scan the list for duplicated classes. If any are found, remove all but one
occurrence, leaving the *last* one in the list. In the above example, the list
- becomes [:class:`D`, :class:`B`, :class:`C`, :class:`A`] after dropping
+ becomes [:class:`!D`, :class:`!B`, :class:`!C`, :class:`!A`] after dropping
duplicates.
-Following this rule, referring to :meth:`D.save` will return :meth:`C.save`,
+Following this rule, referring to :meth:`!D.save` will return :meth:`!C.save`,
which is the behaviour we're after. This lookup rule is the same as the one
followed by Common Lisp. A new built-in function, :func:`super`, provides a way
to get at a class's superclasses without having to reimplement Python's
algorithm. The most commonly used form will be ``super(class, obj)``, which
returns a bound superclass object (not the actual class object). This form
will be used in methods to call a method in the superclass; for example,
-:class:`D`'s :meth:`save` method would look like this::
+:class:`!D`'s :meth:`!save` method would look like this::
class D (B,C):
def save (self):
@@ -309,7 +309,7 @@ Attribute Access
----------------
A fair number of sophisticated Python classes define hooks for attribute access
-using :meth:`__getattr__`; most commonly this is done for convenience, to make
+using :meth:`~object.__getattr__`; most commonly this is done for convenience, to make
code more readable by automatically mapping an attribute access such as
``obj.parent`` into a method call such as ``obj.get_parent``. Python 2.2 adds
some new ways of controlling attribute access.
@@ -321,22 +321,22 @@ instance's dictionary.
New-style classes also support a new method,
``__getattribute__(attr_name)``. The difference between the two methods is
-that :meth:`__getattribute__` is *always* called whenever any attribute is
-accessed, while the old :meth:`__getattr__` is only called if ``foo`` isn't
+that :meth:`~object.__getattribute__` is *always* called whenever any attribute is
+accessed, while the old :meth:`~object.__getattr__` is only called if ``foo`` isn't
found in the instance's dictionary.
However, Python 2.2's support for :dfn:`properties` will often be a simpler way
-to trap attribute references. Writing a :meth:`__getattr__` method is
+to trap attribute references. Writing a :meth:`!__getattr__` method is
complicated because to avoid recursion you can't use regular attribute accesses
inside them, and instead have to mess around with the contents of
-:attr:`~object.__dict__`. :meth:`__getattr__` methods also end up being called by Python
-when it checks for other methods such as :meth:`__repr__` or :meth:`__coerce__`,
+:attr:`~object.__dict__`. :meth:`~object.__getattr__` methods also end up being called by Python
+when it checks for other methods such as :meth:`~object.__repr__` or :meth:`!__coerce__`,
and so have to be written with this in mind. Finally, calling a function on
every attribute access results in a sizable performance loss.
:class:`property` is a new built-in type that packages up three functions that
get, set, or delete an attribute, and a docstring. For example, if you want to
-define a :attr:`size` attribute that's computed, but also settable, you could
+define a :attr:`!size` attribute that's computed, but also settable, you could
write::
class C(object):
@@ -355,9 +355,9 @@ write::
"Storage size of this instance")
That is certainly clearer and easier to write than a pair of
-:meth:`__getattr__`/:meth:`__setattr__` methods that check for the :attr:`size`
+:meth:`!__getattr__`/:meth:`!__setattr__` methods that check for the :attr:`!size`
attribute and handle it specially while retrieving all other attributes from the
-instance's :attr:`~object.__dict__`. Accesses to :attr:`size` are also the only ones
+instance's :attr:`~object.__dict__`. Accesses to :attr:`!size` are also the only ones
which have to perform the work of calling a function, so references to other
attributes run at their usual speed.
@@ -447,7 +447,7 @@ an iterator for the object *obj*, while ``iter(C, sentinel)`` returns an
iterator that will invoke the callable object *C* until it returns *sentinel* to
signal that the iterator is done.
-Python classes can define an :meth:`__iter__` method, which should create and
+Python classes can define an :meth:`!__iter__` method, which should create and
return a new iterator for the object; if the object is its own iterator, this
method can just return ``self``. In particular, iterators will usually be their
own iterators. Extension types implemented in C can implement a :c:member:`~PyTypeObject.tp_iter`
@@ -478,7 +478,7 @@ there are no more values to be returned, calling :meth:`next` should raise the
In 2.2, Python's :keyword:`for` statement no longer expects a sequence; it
expects something for which :func:`iter` will return an iterator. For backward
compatibility and convenience, an iterator is automatically constructed for
-sequences that don't implement :meth:`__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so
+sequences that don't implement :meth:`!__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so
``for i in [1,2,3]`` will still work. Wherever the Python interpreter loops
over a sequence, it's been changed to use the iterator protocol. This means you
can do things like this::
@@ -510,8 +510,8 @@ Iterator support has been added to some of Python's basic types. Calling
Oct 10
That's just the default behaviour. If you want to iterate over keys, values, or
-key/value pairs, you can explicitly call the :meth:`iterkeys`,
-:meth:`itervalues`, or :meth:`iteritems` methods to get an appropriate iterator.
+key/value pairs, you can explicitly call the :meth:`!iterkeys`,
+:meth:`!itervalues`, or :meth:`!iteritems` methods to get an appropriate iterator.
In a minor related change, the :keyword:`in` operator now works on dictionaries,
so ``key in dict`` is now equivalent to ``dict.has_key(key)``.
@@ -580,7 +580,7 @@ allowed inside the :keyword:`!try` block of a
:keyword:`try`...\ :keyword:`finally` statement; read :pep:`255` for a full
explanation of the interaction between :keyword:`!yield` and exceptions.)
-Here's a sample usage of the :func:`generate_ints` generator::
+Here's a sample usage of the :func:`!generate_ints` generator::
>>> gen = generate_ints(3)
>>> gen
@@ -641,7 +641,7 @@ like::
sentence := "Store it in the neighboring harbor"
if (i := find("or", sentence)) > 5 then write(i)
-In Icon the :func:`find` function returns the indexes at which the substring
+In Icon the :func:`!find` function returns the indexes at which the substring
"or" is found: 3, 23, 33. In the :keyword:`if` statement, ``i`` is first
assigned a value of 3, but 3 is less than 5, so the comparison fails, and Icon
retries it with the second value of 23. 23 is greater than 5, so the comparison
@@ -671,7 +671,7 @@ PEP 237: Unifying Long Integers and Integers
In recent versions, the distinction between regular integers, which are 32-bit
values on most machines, and long integers, which can be of arbitrary size, was
becoming an annoyance. For example, on platforms that support files larger than
-``2**32`` bytes, the :meth:`tell` method of file objects has to return a long
+``2**32`` bytes, the :meth:`!tell` method of file objects has to return a long
integer. However, there were various bits of Python that expected plain integers
and would raise an error if a long integer was provided instead. For example,
in Python 1.5, only regular integers could be used as a slice index, and
@@ -752,7 +752,7 @@ Here are the changes 2.2 introduces:
0.5. Without the ``__future__`` statement, ``/`` still means classic division.
The default meaning of ``/`` will not change until Python 3.0.
-* Classes can define methods called :meth:`__truediv__` and :meth:`__floordiv__`
+* Classes can define methods called :meth:`~object.__truediv__` and :meth:`~object.__floordiv__`
to overload the two division operators. At the C level, there are also slots in
the :c:type:`PyNumberMethods` structure so extension types can define the two
operators.
@@ -785,17 +785,17 @@ support.)
When built to use UCS-4 (a "wide Python"), the interpreter can natively handle
Unicode characters from U+000000 to U+110000, so the range of legal values for
-the :func:`unichr` function is expanded accordingly. Using an interpreter
+the :func:`!unichr` function is expanded accordingly. Using an interpreter
compiled to use UCS-2 (a "narrow Python"), values greater than 65535 will still
-cause :func:`unichr` to raise a :exc:`ValueError` exception. This is all
+cause :func:`!unichr` to raise a :exc:`ValueError` exception. This is all
described in :pep:`261`, "Support for 'wide' Unicode characters"; consult it for
further details.
Another change is simpler to explain. Since their introduction, Unicode strings
-have supported an :meth:`encode` method to convert the string to a selected
+have supported an :meth:`!encode` method to convert the string to a selected
encoding such as UTF-8 or Latin-1. A symmetric ``decode([*encoding*])``
method has been added to 8-bit strings (though not to Unicode strings) in 2.2.
-:meth:`decode` assumes that the string is in the specified encoding and decodes
+:meth:`!decode` assumes that the string is in the specified encoding and decodes
it, returning whatever is returned by the codec.
Using this new feature, codecs have been added for tasks not directly related to
@@ -819,10 +819,10 @@ encoding, and compression with the :mod:`zlib` module::
>>> "sheesh".encode('rot-13')
'furrfu'
-To convert a class instance to Unicode, a :meth:`__unicode__` method can be
-defined by a class, analogous to :meth:`__str__`.
+To convert a class instance to Unicode, a :meth:`!__unicode__` method can be
+defined by a class, analogous to :meth:`!__str__`.
-:meth:`encode`, :meth:`decode`, and :meth:`__unicode__` were implemented by
+:meth:`!encode`, :meth:`!decode`, and :meth:`!__unicode__` were implemented by
Marc-André Lemburg. The changes to support using UCS-4 internally were
implemented by Fredrik Lundh and Martin von Löwis.
@@ -859,7 +859,7 @@ doesn't work::
return g(value-1) + 1
...
-The function :func:`g` will always raise a :exc:`NameError` exception, because
+The function :func:`!g` will always raise a :exc:`NameError` exception, because
the binding of the name ``g`` isn't in either its local namespace or in the
module-level namespace. This isn't much of a problem in practice (how often do
you recursively define interior functions like this?), but this also made using
@@ -915,7 +915,7 @@ To make the preceding explanation a bit clearer, here's an example::
Line 4 containing the ``exec`` statement is a syntax error, since
``exec`` would define a new local variable named ``x`` whose value should
-be accessed by :func:`g`.
+be accessed by :func:`!g`.
This shouldn't be much of a limitation, since ``exec`` is rarely used in
most Python code (and when it is used, it's often a sign of a poor design
@@ -933,7 +933,7 @@ anyway).
New and Improved Modules
========================
-* The :mod:`xmlrpclib` module was contributed to the standard library by Fredrik
+* The :mod:`!xmlrpclib` module was contributed to the standard library by Fredrik
Lundh, providing support for writing XML-RPC clients. XML-RPC is a simple
remote procedure call protocol built on top of HTTP and XML. For example, the
following snippet retrieves a list of RSS channels from the O'Reilly Network,
@@ -956,7 +956,7 @@ New and Improved Modules
# 'description': 'A utility which converts HTML to XSL FO.',
# 'title': 'html2fo 0.3 (Default)'}, ... ]
- The :mod:`SimpleXMLRPCServer` module makes it easy to create straightforward
+ The :mod:`!SimpleXMLRPCServer` module makes it easy to create straightforward
XML-RPC servers. See http://xmlrpc.scripting.com/ for more information about XML-RPC.
* The new :mod:`hmac` module implements the HMAC algorithm described by
@@ -964,9 +964,9 @@ New and Improved Modules
* Several functions that originally returned lengthy tuples now return
pseudo-sequences that still behave like tuples but also have mnemonic attributes such
- as memberst_mtime or :attr:`tm_year`. The enhanced functions include
- :func:`stat`, :func:`fstat`, :func:`statvfs`, and :func:`fstatvfs` in the
- :mod:`os` module, and :func:`localtime`, :func:`gmtime`, and :func:`strptime` in
+ as :attr:`!memberst_mtime` or :attr:`!tm_year`. The enhanced functions include
+ :func:`~os.stat`, :func:`~os.fstat`, :func:`~os.statvfs`, and :func:`~os.fstatvfs` in the
+ :mod:`os` module, and :func:`~time.localtime`, :func:`~time.gmtime`, and :func:`~time.strptime` in
the :mod:`time` module.
For example, to obtain a file's size using the old tuples, you'd end up writing
@@ -999,7 +999,7 @@ New and Improved Modules
underlying the :mod:`re` module. For example, the :func:`re.sub` and
:func:`re.split` functions have been rewritten in C. Another contributed patch
speeds up certain Unicode character ranges by a factor of two, and a new
- :meth:`finditer` method that returns an iterator over all the non-overlapping
+ :meth:`~re.finditer` method that returns an iterator over all the non-overlapping
matches in a given string. (SRE is maintained by Fredrik Lundh. The
BIGCHARSET patch was contributed by Martin von Löwis.)
@@ -1012,33 +1012,33 @@ New and Improved Modules
new extensions: the NAMESPACE extension defined in :rfc:`2342`, SORT, GETACL and
SETACL. (Contributed by Anthony Baxter and Michel Pelletier.)
-* The :mod:`rfc822` module's parsing of email addresses is now compliant with
+* The :mod:`!rfc822` module's parsing of email addresses is now compliant with
:rfc:`2822`, an update to :rfc:`822`. (The module's name is *not* going to be
changed to ``rfc2822``.) A new package, :mod:`email`, has also been added for
parsing and generating e-mail messages. (Contributed by Barry Warsaw, and
arising out of his work on Mailman.)
-* The :mod:`difflib` module now contains a new :class:`Differ` class for
+* The :mod:`difflib` module now contains a new :class:`!Differ` class for
producing human-readable lists of changes (a "delta") between two sequences of
- lines of text. There are also two generator functions, :func:`ndiff` and
- :func:`restore`, which respectively return a delta from two sequences, or one of
+ lines of text. There are also two generator functions, :func:`!ndiff` and
+ :func:`!restore`, which respectively return a delta from two sequences, or one of
the original sequences from a delta. (Grunt work contributed by David Goodger,
from ndiff.py code by Tim Peters who then did the generatorization.)
-* New constants :const:`ascii_letters`, :const:`ascii_lowercase`, and
- :const:`ascii_uppercase` were added to the :mod:`string` module. There were
- several modules in the standard library that used :const:`string.letters` to
+* New constants :const:`!ascii_letters`, :const:`!ascii_lowercase`, and
+ :const:`!ascii_uppercase` were added to the :mod:`string` module. There were
+ several modules in the standard library that used :const:`!string.letters` to
mean the ranges A-Za-z, but that assumption is incorrect when locales are in
- use, because :const:`string.letters` varies depending on the set of legal
+ use, because :const:`!string.letters` varies depending on the set of legal
characters defined by the current locale. The buggy modules have all been fixed
- to use :const:`ascii_letters` instead. (Reported by an unknown person; fixed by
+ to use :const:`!ascii_letters` instead. (Reported by an unknown person; fixed by
Fred L. Drake, Jr.)
* The :mod:`mimetypes` module now makes it easier to use alternative MIME-type
- databases by the addition of a :class:`MimeTypes` class, which takes a list of
+ databases by the addition of a :class:`~mimetypes.MimeTypes` class, which takes a list of
filenames to be parsed. (Contributed by Fred L. Drake, Jr.)
-* A :class:`Timer` class was added to the :mod:`threading` module that allows
+* A :class:`~threading.Timer` class was added to the :mod:`threading` module that allows
scheduling an activity to happen at some future time. (Contributed by Itamar
Shtull-Trauring.)
@@ -1114,7 +1114,7 @@ code, none of the changes described here will affect you very much.
* Two new wrapper functions, :c:func:`PyOS_snprintf` and :c:func:`PyOS_vsnprintf`
were added to provide cross-platform implementations for the relatively new
:c:func:`snprintf` and :c:func:`vsnprintf` C lib APIs. In contrast to the standard
- :c:func:`sprintf` and :c:func:`vsprintf` functions, the Python versions check the
+ :c:func:`sprintf` and :c:func:`!vsprintf` functions, the Python versions check the
bounds of the buffer used to protect against buffer overruns. (Contributed by
M.-A. Lemburg.)
@@ -1212,12 +1212,12 @@ Some of the more notable changes are:
* The :file:`Tools/scripts/ftpmirror.py` script now parses a :file:`.netrc`
file, if you have one. (Contributed by Mike Romberg.)
-* Some features of the object returned by the :func:`xrange` function are now
+* Some features of the object returned by the :func:`!xrange` function are now
deprecated, and trigger warnings when they're accessed; they'll disappear in
- Python 2.3. :class:`xrange` objects tried to pretend they were full sequence
+ Python 2.3. :class:`!xrange` objects tried to pretend they were full sequence
types by supporting slicing, sequence multiplication, and the :keyword:`in`
operator, but these features were rarely used and therefore buggy. The
- :meth:`tolist` method and the :attr:`start`, :attr:`stop`, and :attr:`step`
+ :meth:`!tolist` method and the :attr:`!start`, :attr:`!stop`, and :attr:`!step`
attributes are also being deprecated. At the C level, the fourth argument to
the :c:func:`!PyRange_New` function, ``repeat``, has also been deprecated.
1
0
![](https://secure.gravatar.com/avatar/cc7737cd64a84f1b5c61a160798e97ee.jpg?s=120&d=mm&r=g)
[3.12] gh-114685: Fix incorrect use of PyBUF_READ in import.c (GH-114686) (GH-114700)
by serhiy-storchaka 29 Jan '24
by serhiy-storchaka 29 Jan '24
29 Jan '24
https://github.com/python/cpython/commit/2a1d2c83256e6445793ec8b79363e4ac44…
commit: 2a1d2c83256e6445793ec8b79363e4ac4494db78
branch: 3.12
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: serhiy-storchaka <storchaka(a)gmail.com>
date: 2024-01-29T10:09:51Z
summary:
[3.12] gh-114685: Fix incorrect use of PyBUF_READ in import.c (GH-114686) (GH-114700)
(cherry picked from commit 1ac1b2f9536a581f1656f0ac9330a7382420cda1)
Co-authored-by: Nikita Sobolev <mail(a)sobolevn.me>
files:
M Python/import.c
diff --git a/Python/import.c b/Python/import.c
index 54232a130082f0..db70909982fa3e 100644
--- a/Python/import.c
+++ b/Python/import.c
@@ -3570,7 +3570,7 @@ _imp_get_frozen_object_impl(PyObject *module, PyObject *name,
struct frozen_info info = {0};
Py_buffer buf = {0};
if (PyObject_CheckBuffer(dataobj)) {
- if (PyObject_GetBuffer(dataobj, &buf, PyBUF_READ) != 0) {
+ if (PyObject_GetBuffer(dataobj, &buf, PyBUF_SIMPLE) != 0) {
return NULL;
}
info.data = (const char *)buf.buf;
1
0
![](https://secure.gravatar.com/avatar/cc7737cd64a84f1b5c61a160798e97ee.jpg?s=120&d=mm&r=g)
[3.11] gh-114685: Fix incorrect use of PyBUF_READ in import.c (GH-114686) (GH-114701)
by serhiy-storchaka 29 Jan '24
by serhiy-storchaka 29 Jan '24
29 Jan '24
https://github.com/python/cpython/commit/ee3ca96359a27e893e4f642b3d490a7d35…
commit: ee3ca96359a27e893e4f642b3d490a7d355f7da7
branch: 3.11
author: Miss Islington (bot) <31488909+miss-islington(a)users.noreply.github.com>
committer: serhiy-storchaka <storchaka(a)gmail.com>
date: 2024-01-29T10:03:14Z
summary:
[3.11] gh-114685: Fix incorrect use of PyBUF_READ in import.c (GH-114686) (GH-114701)
(cherry picked from commit 1ac1b2f9536a581f1656f0ac9330a7382420cda1)
Co-authored-by: Nikita Sobolev <mail(a)sobolevn.me>
files:
M Python/import.c
diff --git a/Python/import.c b/Python/import.c
index 39144d302193ac..c4e2145a47c4d2 100644
--- a/Python/import.c
+++ b/Python/import.c
@@ -2194,7 +2194,7 @@ _imp_get_frozen_object_impl(PyObject *module, PyObject *name,
struct frozen_info info = {0};
Py_buffer buf = {0};
if (PyObject_CheckBuffer(dataobj)) {
- if (PyObject_GetBuffer(dataobj, &buf, PyBUF_READ) != 0) {
+ if (PyObject_GetBuffer(dataobj, &buf, PyBUF_SIMPLE) != 0) {
return NULL;
}
info.data = (const char *)buf.buf;
1
0