[Python-Dev] Surely "nullable" is a reasonable name?

[Larry Hastings]

On 08/04/2014 05:46 PM, Glenn Linderman 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.

Argument Clinic defines *both* sides of how things are done in builtins, 
both C and Python.  So it's a bit messier than that. Currently the 
"nullable" flag is only applicable to certain converters which output 
pointer types in C, so if it gets a None for that argument it does 
provide a NULL as the C equivalent.  But in the "nullable int" patch 
obviously I can't do that.  Instead you get a structure containing 
either an int or a flag specifying "you got a None", currently named 
"is_null".  So I don't think your proposed additional justification helps.

Of course, in my opinion I don't need this additional justification.  
Python's "None" is its null object.  And we already have the concept of 
"nullable types" in computer science, for exactly, *exactly!*, this 
concept.  As the Zen says, "special cases aren't special enough to break 
the rules".  Just because Python is silly enough to name its null object 
"None" doesn't mean we have to warp all our other names around it.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140805/6deebd85/attachment.html>