[Python-Dev] Surely "nullable" is a reasonable name?
v+python at g.nevcal.com
Mon Aug 4 09:46:25 CEST 2014
On 8/4/2014 12:35 AM, Stephen Hansen wrote:
> On Mon, Aug 4, 2014 at 12:12 AM, Larry Hastings <larry at hastings.org
> <mailto:larry at hastings.org>> wrote:
> Several people have said they found the name "nullable"
> surprising, suggesting I use another name like "allow_none" or
> "noneable". I, in turn, find their surprise surprising;
> "nullable" is a term long associated with exactly this concept.
> It's used in C# and SQL, and the term even has its own Wikipedia page:
> The thing is, "null" in these languages are not the same thing. If you
> look to the various database wrappers there's a lot of controversy
> about just how to map the SQL NULL to Python: simply mapping it to
> Python's None becomes strange because the semantics of a SQL NULL or
> NULL pointer and Python None don't exactly match. Not all that long
> ago someone was making an argument on this list to add a SQLNULL type
> object to better map SQL NULL semantics (regards to sorting, as I
> recall -- but its been awhile)
> Python has None. Its definition and understanding in a Python context
> is clear. Why introduce some other concept? In Python its very common
> you pass None instead of an other argument.
> Before you say "the term 'nullable' will confuse end users", let
> me remind you: this is not user-facing. This is a parameter for
> an Argument Clinic converter, and will only ever be seen by
> CPython core developers. A group which I hope is not so easily
> Yet, my lurking observation of argument clinic is it is all about
> clearly defining the C-side of how things are done in Python API's. It
> may not confuse 'end users', but it may confuse possible contributors,
> and simply add a lack of clarity to the situation.
> Passing None in place of another argument is a very Pythonic thing to
> do; why confuse that by using other words which imply other semantics?
> None is a Python thing with clear semantics in Python; allow_none
> quite accurately describes the Pythonic thing described here, while
> 'nullable' expects for domain knowledge beyond Python and makes
> assumptions of semantics.
Thanks, Stephen. +1 to all you wrote.
There remains, of course, one potential justification for using
"nullable", that you didn't make 100% clear. Because "argument clinic is
it is all about clearly defining the C-side of how things are done in
Python API's." and that is that C uses NULL (but it is only a
convention, not a language feature) for missing reference parameters on
occasion. But I think it is much more clear that if C NULL gets mapped
to Python None, and we are talking about Python parameters, then a
NULLable C parameter should map to an "allow_none" Python parameter.
The concepts of C NULL, C# NULL, SQL NULL, and Python None are all
slightly different, even the brilliant people on python-dev could better
spend their energies on new features and bug fixes rather than being
slowed by the need to remember yet another unclear and inconsistent
terminology issue, of which there are already too many.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev