[New-bugs-announce] [issue24145] Support |= for parameters in converters

[Larry Hastings]

New submission from Larry Hastings:

Some "format units" provided by PyArg_ParseTuple() are exactly the same as others, except that they also accept the value None.  For example, "s" and "z" are exactly the same, except "z" accepts None and "s" does not.  The same goes for "s*" and "z*", or "s#" and "z#".

To tell an Argument Clinic converter which types of objects it should accept, one would pass in the "accept" named parameter.  We now use this facility for the "also accept None" format units.  "z" is the same as "s", except that for "z" you add NoneType to the list of types passed in for "accept".  Like so:

    str1: str()                       # format unit 's'
    str2: str(accept={str, NoneType}) # format unit 'z'

The trick here is, the default value for the 'accept' parameter for the str() converter is {str}.  But you have to know that in order to add NoneType to it.

It'd be nice if there were some way of saying "take the existing default value for parameter X, and add value Y to it".  Then for the "accept" parameter you could just add NoneType to it.  You might say, "yeah, but Python doesn't have anything like that".  To which I say, Argument Clinic isn't Python.  It leverages Python syntax (using ast.parse) but we need not be bound by what Python does.  We could maybe add a little syntax or play with the semantics to add this functionality.

We discussed this on c.l.p-d a little, and some folks took the opportunity to play a little syntax golf with the idea.  (Everybody who participated in the thread writ large got Cc'd on this bug, congratulations, you're welcome!)  Ultimately there was only one syntax I liked, which (no surprise) was one I suggested:

    str2: str(accept|={NoneType})

accept's default value is a set, and sets use | as the union operator.  And Python actually has a |= statement, although it doesn't work in function calls like that.  But that means readers unfamiliar with Argument Clinic should be able to quickly intuit what the syntax means.  It also meant I could use the tokenize module to do a proper job of the implementation.

So I ask you: do we want this?  Advantages and disadvantages as I see them:

+ : Don't Repeat Yourself.
+ : You don't have to look up the default types to add NoneType to it/them.
- : Startling syntax, makes Clinic a little weirder

Take a look at the diffs and decide whether the new syntax is an improvement.  (You can look at the implementation too, of course, if you're curious.  But IMO the implementation is fine, and ready to go in if we want it.)

----------
assignee: larry
components: Argument Clinic
files: larry.clinic.or.equals.for.parameters.1.txt
messages: 242756
nosy: barry, gregory.p.smith, larry, ncoghlan, serhiy.storchaka, taleinat, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Support |= for parameters in converters
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39322/larry.clinic.or.equals.for.parameters.1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24145>
_______________________________________