However, there are no plans to remove support for it.
In single-phase initialization, the old-style
-:ref:`initializaton function <extension-pyinit>` (``PyInit_modulename``)
+:ref:`initialization function <extension-pyinit>` (``PyInit_modulename``)
should create, populate and return a module object.
This is typically done using :c:func:`PyModule_Create` and functions like
:c:func:`PyModule_AddObjectRef`.
behave as if it was created from that :c:type:`PyModuleDef`.
In particular, the module state must have matching layout and semantics.
- Modules created from :c:type:`PyModuleDef` allways use the address of
+ Modules created from :c:type:`PyModuleDef` always use the address of
the :c:type:`PyModuleDef` as the token.
This means that :c:macro:`!Py_mod_token` cannot be used in
:c:member:`PyModuleDef.m_slots`.
Added parameters *inherit_class_doc* and *fallback_to_class_doc*.
Documentation strings on :class:`~functools.cached_property`
- objects are now inherited if not overriden.
+ objects are now inherited if not overridden.
.. function:: getcomments(object)
string contents.
* In ``fstring_replacement_field``, if ``f_debug_specifier`` is present,
all whitespace after the opening brace until the ``f_debug_specifier``,
- as well as whitespace immediatelly following ``f_debug_specifier``,
+ as well as whitespace immediately following ``f_debug_specifier``,
is retained as part of the expression.
.. impl-detail::