[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
I will also say that I don't believe the safe-navigation operators necessarily compromise type safety. PEP 505 explicitly rejects having them catch `AttributeError` or `KeyError` (and I agree with this rejection). It's not the default behavior of objects to return None when an unknown attribute is read, so attempting to access `book?.publisher?.onwer?.name` will still fail with `AttributeError`. Type checkers would also continue being able to check such navigation. 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/V4PK74K7W74EJ5XMXPEB6FLAZCDJ6SCN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Steven D'Aprano wrote: > Hello Doug, > On Thu, Oct 14, 2021 at 03:45:07PM -, 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/QDUJ6SIZWUMJ6YJDJRYZ4JA2GKSLJJ7I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 505 (None-aware operators) for Python 3.11
Hello, I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/) since it was first proposed for Python 3.8. It's been deferred for some time and I'm interested in seeing it in Python 3.11, but I know there were also a number of objections which resulted in it being deferred (including by one of the original authors, Mr. Dower). I did email both Mr. Dower and Mr. Haase and they graciously gave me their permission to bring it up on this list for discussion and hopefully final pronouncement one way or the other. I personally believe that the PEP will result in a significant reduction in boilerplate code, and it is substantially similar to the same operators now found in a number of other languages, especially C# and JavaScript (https://wikipedia.org/wiki/Null_coalescing_operator and https://wikipedia.org/wiki/Safe_navigation_operator). I believe strong and valid arguments can be made about the use of None being a fundamental flaw in some types of coding (and that adding additional support for it to the language will increase the use of None in this way), but I also believe there are many use cases in programming where it is by far the simplest way to express various semantics, and the fact exists that None is already used extensively in large quantities of code, and further that there is already a great deal of code written to constantly test against None and break out of a statement without throwing an error. I also understand the argument that especially the maybe-dot (?.) and maybe-subscript (?[) operators can decrease readability of code and also believe these are valid arguments against it. While I believe the existence and use of these operators in other languages definitely helps the case that these can be used and understood successfully, I think it is entirely valid to either consider other syntax (though I prefer the chosen syntax of PEP 505), or even to reduce PEP 505 to having only the coalesce operator (??) and the maybe-assign operator (??=). Separately, I have implemented a pure-Python solution for PEP505 (which is definitely rather beta) which might help test the waters for a final implementation in CPython (though the CPython implementation would of course be much more efficient). It can be found at https://pypi.org/project/pep505/ Thanks, 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/XZZIV42XGG3EIHRBBCCTTCFPWWSOT7MX/ Code of Conduct: http://python.org/psf/codeofconduct/
