[Python-ideas] PEP 505 (None coalescing operators) thoughts

Terry Reedy tjreedy at udel.edu
Tue Sep 29 23:48:22 CEST 2015

On 9/29/2015 12:35 PM, Sven R. Kunze wrote:
> On 29.09.2015 02:38, Terry Reedy wrote:
>> On 9/28/2015 5:48 PM, Luciano Ramalho wrote:
>>> Glyph tweeted yesterday that everyone should watch the "Nothing is
>>> Something" 35' talk by Sandi Metz at RailsConf 2015. It's great and,
>>> in a way, relevant to this discussion.
>>> https://www.youtube.com/watch?v=29MAL8pJImQ
>> I understood Metz as advocation avoidig the nil (None) problem by
>> giving every class an 'active nothing' that has the methods of the
>> class.  We do that for most builtin classes -- 0, (), {}, etc. She
>> also used the identity function with a particular signature in various
>> roles.
> I might stress here that nobody said there's a single "active nothing".

Ruby's nil and Python's None are passibe nothings.  Any operation other 
than those inherited from Object raise an exception.

> There are far more "special case objects" (as Robert C. Martin calls it)
> than 0, (), {}, etc.

Metz's point is that there is potentially one for most classes than one 
might write.

Some people have wondered why Python does not come with a builtin 
identity function.  The answer has been that one is not needed much and 
and it is easy to create one.  Metz's answer is that they are very 
useful for generalizing classes.  But she also at least implied that 
they should be specific to each situation.  Certainly in Python, if code 
were to check signature, and even type annotation, then a matching id 
function would be needed.

> I fear, however, the stdlib cannot account for
 > every special case object possible.

Right.  It is not possible to create a null instance of a class that 
does not yet exist.

> Without None available in the first place,

The problem of a general object is that it is general.  It should either 
be a ghost that does nothing, as with None, or a borg than does 
everything, as with the Bottom of some languages.

 >  users would be forced to create their domain-specific special
 > case objects.

Metz recomends doing this voluntarily ;-)
perhaps after an initial prototype.

 > None being available though, people need to be taught to avoid it,
 > which btw. she did a really good job of.

I think None works really well as the always-returned value for 
functions that are really procedures.  The problem comes with returning 
something or None, versus something or raise, or something or null of 
the class of something.

Terry Jan Reedy

More information about the Python-ideas mailing list