New proposed semantics for the types= parameter to converters: where possible, pass in actual types.  The resulting syntax:  c: int(types={str}) # maps to 'U'  s: str(types={str, robuffer}, length=True, zeroes=True) # maps to 's#'Since "buffer", "robuffer", and "rwbuffer" are fake pseudotypes, I created empty classes with those names.Serhiy: with this change in place, the types= parameter uses almost the same number of characters as it used to when it was a string.  (The new syntax requires commas between elements, so for two or more types it's slightly longer.)  Yet this makes the types= parameter far more accurate in illustrating what it's supposed to represent.Does this make you happy? :)

Should types= be renamed accept= ?  It's a set of the types of the Python objects that this parameter should accept.

I should mention that evalify_node() is pretty hacked up here, and is not ready to be checked in.  (I'm proposing separately that we simply add something like this directly into the standard library, see issue#24002.)

accept= (or accept_types=) LGTM.

Thanks to#24002 I now know how to write evalify_node properly.  This revision of the patch is much better, and maybe ready for checkin.

Looks as this is a patch for different issue.

Whoops.  I'll fix that.

Here's the right patch.

Attached is a patch implementing all my proposed changes here:* "types" is now renamed "accept"* it accepts a set of real Python types* there are placeholder types for buffer, robuffer, rwbuffer* "nullable=True" is gone, replaced with adding NoneType to accept={}

Usually converters are named by the C type of the result. May be rename the "str" converter to "pchar"?

New changeset41fb7fd04b5d by Larry Hastings in branch 'default':Issue#24001: Argument Clinic converters now use accept={type}https://hg.python.org/cpython/rev/41fb7fd04b5d