@@ -640,7 +640,7 @@ on the right is the text you'd replace it with.
640640``'K' `` ``unsigned_PY_LONG_LONG ``
641641``'L' `` ``PY_LONG_LONG ``
642642``'n' `` ``Py_ssize_t ``
643- ``'O!' `` ``object(type='name_of_Python_type ') ``
643+ ``'O!' `` ``object(subclass_of='&PySomething_Type ') ``
644644``'O&' `` ``object(converter='name_of_c_function') ``
645645``'O' `` ``object ``
646646``'p' `` ``bool ``
@@ -693,20 +693,22 @@ conversion functions, or types, or strings specifying an encoding.
693693(But "legacy converters" don't support arguments. That's why we
694694skipped them for your first function.) The argument you specified
695695to the format unit is now an argument to the converter; this
696- argument is either ``converter `` (for ``O& ``), ``type `` (for ``O! ``),
696+ argument is either ``converter `` (for ``O& ``), ``subclass_of `` (for ``O! ``),
697697or ``encoding `` (for all the format units that start with ``e ``).
698698
699- Note that ``object() `` must explicitly support each Python type you specify
700- for the ``type `` argument. Currently it only supports ``str ``. It should be
701- easy to add more, just edit ``Tools/clinic/clinic.py ``, search for ``O! `` in
702- the text, and add more entries to the dict mapping types to strings just above it.
699+ When using ``subclass_of ``, you may also want to use the other
700+ custom argument for ``object() ``: ``type ``, which lets you set the type
701+ actually used for the parameter. For example, if you want to ensure
702+ that the object is a subclass of ``PyUnicode_Type ``, you probably want
703+ to use the converter ``object(type='PyUnicodeObject *', subclass_of='&PyUnicode_Type') ``.
703704
704- Note also that this approach takes away some possible flexibility for the format
705- units starting with ``e ``. It used to be possible to decide at runtime what
705+ One possible problem with using Argument Clinic: it takes away some possible
706+ flexibility for the format units starting with ``e ``. When writing a
707+ ``PyArg_Parse `` call by hand, you could theoretically decide at runtime what
706708encoding string to pass in to :c:func: `PyArg_ParseTuple `. But now this string must
707- be hard-coded at compile- time. This limitation is deliberate; it made supporting
708- this format unit much easier, and may allow for future compile-time optimizations.
709- This restriction does not seem unreasonable; CPython itself always passes in static
709+ be hard-coded at Argument-Clinic-preprocessing- time. This limitation is deliberate;
710+ it made supporting this format unit much easier, and may allow for future optimizations.
711+ This restriction doesn't seem unreasonable; CPython itself always passes in static
710712hard-coded encoding strings for parameters whose format units start with ``e ``.
711713
712714
@@ -796,7 +798,8 @@ block, and ensure that its converter is an instance of
796798``self_converter `` or a subclass thereof.
797799
798800What's the point? This lets you automatically cast ``self ``
799- from ``PyObject * `` to a custom type.
801+ from ``PyObject * `` to a custom type, just like ``object() ``
802+ does with its ``type `` parameter.
800803
801804How do you specify the custom type you want to cast ``self `` to?
802805If you only have one or two functions with the same type for ``self ``,
0 commit comments