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 bpo-24002.)

Thanks to bpo-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 changeset 41fb7fd04b5d by Larry Hastings in branch 'default':
Issue bpo-24001: Argument Clinic converters now use accept={type}
https://hg.python.org/cpython/rev/41fb7fd04b5d