NoneType is just another type, and in type checking scenarios should be expressed with `Optional[type]` or more preferably in the future `type | None`; `None` is not a non-value. Assuming what I just wrote is true, I don't get what the basis of this thread is; what am I missing?
Thanks for allowing me to speak for myself, as I said I would when
contacted off list :)
But as it happens, you've summarised my position very accurately:
he now believes the implementation of these operators would lead people to a style of coding which would lead to the proliferation of None as an exception-less error result and also throughout data structures. My understanding is that his current preference is to focus on functional composition and styles of programming that disallow the use of None.
As additional context, C# and the .NET Framework have just gone through
the exercise of making (and propagating) non-nullable reference types
(and their "null" is far more like our None than C's NULL). Our type
checkers are also pushing in this direction by requiring Optional[]. The
argument in all cases is that it allows for simpler code that can safely
ignore non-values because they cannot be passed.
Adding ??, ?. and ?[, particularly in their short-circuiting evaluation
form, encourages more complex code by adding value-based branching
within an expression. And it encourages it on the "outside" of the API,
not within it. Which means API designers can more easily justify
returning None because their caller can use None-aware operators to
basically ignore it. (I would argue that the API designer should work
harder to create an API that doesn't ever have to return None.)
To be clear, I'm thinking very much in terms of "impact on what people
will consider to be Pythonic API design over the next 10 years", that
is, what people think they *should* do with this, rather than simply
what they *could*. So it's all very hypothetical and I have no data for
it, much like when it was decided that Optional[] would be mandatory on
types where None is permitted.
And with that, I'm bowing out of the fresh discussion (unless the SC
wants to discuss it directly with me). I'll continue advocating for
tools/features that help people create better APIs, but I'm not going to
spend a lot of time arguing against those that I believe will not.
Cheers,
Steve
On 10/15/2021 3:08 AM, Doug Swarin wrote:
Steven D'Aprano wrote:
Hello Doug,
On Thu, Oct 14, 2021 at 03:45:07PM -0000, Doug Swarin wrote:
I believe strong and valid arguments can be made about the use of None
being a fundamental flaw in some types of coding
Can you elaborate on that? Obviously it is not always appropriate to use
None, but I've never seen it called a *fundamental* flaw.
I know that the null pointer has been called a billion-dollar mistake,
but Python's None is not a null pointer.
I apologize that I may have spoken too strongly here. When I emailed Mr. Dower, he mentioned that he now believes the implementation of these operators would lead people to a style of coding which would lead to the proliferation of None as an exception-less error result and also throughout data structures. My understanding is that his current preference is to focus on functional composition and styles of programming that disallow the use of None.
I certainly don't mean to speak for him and I hope he will weigh in with a more detailed explanation of his thoughts and objections, but I personally disagree as a matter of pure practicality. It's just plain useful to be able to easily take non-values and safely deal with them without having to constantly check for None or to catch and inspect exceptions to see if it's a case that can be ignored.
I did indeed think about connecting None to the 'billion dollar mistake' but decided against it since as you say None is not a null pointer, and I should have chosen my words a little more carefully when revising my initial post (likely by removing the word 'fundamental').
Doug
_______________________________________________