Hi Philipp, That's a really good idea, and I'd really want to see it being implemented. Having said that, I wonder how many people would actually use this concept of "none-representing" objects. In my 10+ years of programming experience I've never seen anybody eager to use more complex structures or object representations of such concepts outside of an academic environment (and even there usually when dealing with personal or proof-of-concept projects). Nowadays I write mostly more business-oriented code, and I haven't been successful in finding a workplace where "business" wants to pay for preparing "good looking" code - they want a functioning one. That's where this whole concept of using none values is used the most (at least from my experience). So to reiterate: I think that the idea presented by Steve is very appealing, and I'd really like to work with such projects, but the reality is that it's really hard to stumble upon such. And I would really much *prefer to have none-aware operators that would make my life easier working with "real world" projects that rely too heavily on none values*, even if it's academically not correct. On Mon, Sep 19, 2022, 17:06 Philipp Burch <phip@hb9etc.ch> wrote:
Hi all,
I've only here found out that there is a discussion going on about those none-aware operators and my first thought was "great, finally!". FWIW, I'd be happy with the syntax suggestion in the PEP, since '?' looks rather intuitive to me to mean something like "maybe".
However, I then read the mentioned post of Steve Dower, with the final summary:
So to summarise my core concern - allowing an API designer to "just use None" is a cop out, and it lets people write lazy/bad APIs rather than coming up with good ones.
This is a very good point. In fact, I've never really thought about it that way and of course he's totally right that "SomeType | None" (or Optional[SomeType], which also somehow made me feel that this usage is fairly intended) is not optimal, at least for user defined types/classes. The problem is, that I never actually thought about his suggested way. And I wouldn't be surprised if this holds for many other people as well.
Maybe it would be great to boldly mention these thoughts in the documentation at an appropriate place. In my opinion, there are at least the following good places where this would fit nicely:
- The documentation of the dataclasses (https://docs.python.org/3/library/dataclasses.html), since this is probably the most common use case for the "| None" pattern. Going further, the dataclasses functionality might even be extended to make it simpler to generate such null-types (or however they are called), so that it is no longer "a tonne more work".
- Linters like pylint could emit a note when seeing the "| None" pattern, linking to the explanation about why it is possibly not the best way to do it.
- The documentation of the discussed None-aware operators. Since these new operators are closely coupled to the arguably suboptimal "| None" pattern, it is probably good to tell folks right there why they should consider better alternatives.
As mentioned, I absolutely see Steve's point. However, there are many Python scripts/programs working without a complex API, where this "| None" pattern may still have its legitimate uses and the none-aware operators can make code easier to read (and write).
Best regards, Philipp _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/Q2MOF5CJ... Code of Conduct: http://python.org/psf/codeofconduct/