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 <rep...@bugs.python.org>
<http://bugs.python.org/issue24145>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
