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?
On Mon, 2021-10-18 at 14:13 +0100, Steve Dower wrote: > 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 > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/UIASDCES7GMQAMBNZGQZ65B2HSCPOEMD/ > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P5QG7HJ2MZPKKRRGAY2JP5LFXZ7UMIA3/ Code of Conduct: http://python.org/psf/codeofconduct/
