Larry Hastings added the comment:
I'm now converging on changing types= to accept a set of real types, see issue
#24001. That change has an impact on this decision.
(By the way, let's assume that if "nullable", I have to rename it to
"accepts_none". I'll use that name below.)
What makes me want to use types={NoneType} is the Zen: "There should be one
(and preferably only one) obvious way to do it", and "Special cases aren't
special enough to break the rules". But Argument Clinic's input isn't Python,
so maybe the Zen doesn't need to be as strict here.
What makes me not want to use types={NoneType} is that it's generally longer,
and it requires you to know the default types accepted by a converter.
Currently (after the rename) to get format unit "z" you write:
s: str(accepts_none=True)
If I changed this (and #24001 goes in), you'd have to write:
s: str(types={str, NoneType})
It requires you to know all the default types of the converter in question,
just so you can add NoneType to it. And it's longer.
We could fix it if converter classes generally published their default types.
So you could say
s: str(types=str_converter.default_types + {NoneType})
And it's even longer. So we probably shouldn't bother with this.
On the other hand, out of all the converters that exist, only three have a
types= argument (int, str, and Py_buffer). And it's not unreasonable to expect
the caller to know the default types= set. Although, we'd have to add types=
to a fourth converter (Py_UNICODE), which currently supports nullable= but
doesn't need types=.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23920>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
