On Mon, Jul 23, 2018 at 12:15:14PM +0100, Paul Moore wrote:
The examples are interesting, agreed. One thing they highlight to me is that most uses of None are effectively convention. The only two behaviours that are unique to None and implemented in the interpreter are:
1. Functions that don't return an explicit value return None.
That is built into the language.
2. The interactive interpreter does not display the value of a typed expression when that value is None.
But that is not built-in, it is merely the default behaviour. It is controlled by sys.displayhook, which can be customized: https://docs.python.org/3/library/sys.html#sys.displayhook We can have many interactive interpreters, including iPython, bpython, IDLE, etc and they don't necessarily suppress the printing of None.
One of the key points about this proposal
That would be the None-aware PEP, not Jonathon's proposal to add documentation about None.
is that it adds a number of additional ways in which the interpreter treats None specially (i.e., four dedicated operators). That elevates None from the position of being a commonly used sentinel value to one that has language support for being a sentinel.
None is already a special value. It is so special, it is one of only three built-in values given keyword status. All the other built-ins, including such things that are used implicitly by the interpreter (such as NotImplemented) are merely ordinary names.
That's not necessarily a bad thing, but it is a point that should be considered when reviewing this PEP (people who prefer to use object() for their sentinels are probably less happy about making None "special",
You make it sound like its a mere aesthetic choice. None is the default, recommended, most convenient sentinel. I use object() as a sentinel, when None is an otherwise ordinary value. I am also happy for None to be special, because it *is* special. -- Steve