[issue23920] Should Clinic have nullable or types=NoneType?
Larry Hastings added the comment: The final version of this has been implemented as part of 41fb7fd04b5d for issue #24001. However, I'll mention here for posterity's sakes: there's an additional discussion on #24145. (Everyone on the nosy list has already been invited to the party!) -- resolution: - fixed stage: test needed - resolved status: open - closed ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
Larry Hastings added the comment: I've implemented this change in the latest patch (#3) for #24001. -- ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
Larry Hastings added the comment: p.s. I'm now leaning heavily towards renaming types to accept, and putting NoneType in the set passed to accept= instead of a separate parameter. -- ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
Larry Hastings added the comment: I've posted about this to python-dev. -- ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
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
[issue23920] Should Clinic have nullable or types=NoneType?
Serhiy Storchaka added the comment: accepts_none=True looks as doesn't accept anything to me. -- ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
Larry Hastings added the comment: Oh, I misremembered. The name allow_none was inflicted on me by python-dev, in this thread: https://mail.python.org/pipermail/python-dev/2014-August/135650.html -- ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
Larry Hastings added the comment: Saying that str is redundant makes me think you don't understand what types does. types accepts a text string listing all of the Python types the converter accepts. You can accept the converter's default, or you can specify your own value. If you specify your own value you must list all the types. So str is not redundant there. The problem with which one is more obvious: we could get rid of nullable and just use types. But we can't get rid of types. If we keep both, now we theoretically have two ways to specify it. Which should you use? Do we say you must use the nullable parameter, you're not allowed to specify NoneType in types, and if so, why? p.s. I promised to rename nullable to accepts_none. Obviously if I just get rid of it I needn't bother. p.p.s. Should types accept a + to mean all the defaults, and...? For example, calling str(types=+ foo) was equivalent to str(types=str foo)? -- ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
New submission from Larry Hastings: I was staring at Clinic tonight and a thought came to me. We could express nullable=True as types='NoneType'. For example, the converter for 'Z' could change from Py_UNICODE(nullable=True) to Py_UNICODE(types=str NoneType) There Should Be Only One Way To Do It. Should we get rid of nullable=True and use types=NoneType instead? FWIW it's pretty arbitrary either way; the arguments to the converter are just telling the converter how to generate the code. I don't think it would make any difference in the converter's code--either way is fine. -- assignee: larry components: Argument Clinic messages: 240534 nosy: larry, serhiy.storchaka, zach.ware priority: normal severity: normal stage: test needed status: open title: Should Clinic have nullable or types=NoneType? type: enhancement versions: Python 3.5 ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
Zachary Ware added the comment: s/Only One/One Obvious/ ;) Which way is more obvious? How would it affect nullable ints? -- ___ 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
[issue23920] Should Clinic have nullable or types=NoneType?
Serhiy Storchaka added the comment: This will break other principle. Don't Repeat Yourself. str for the Py_UNICODE converter looks redundant. -- ___ 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
