[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