On Sun, Sep 18, 2022 at 09:43:26PM +0200, Philipp Burch wrote:
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.
I don't think that `SomeType|None` is necessarily a lazy or bad API. Whether it is "optimal" or not will depend on the specific SomeType involved, not to mention other tradeoffs and constraints such as time and money available. (Oh, to have the luxury of spending two months to "Do It Right" for a project needed in a week on a budget...) But what's not "optimal" is expecting everyone who writes a class and needs to represent the lack of an instance to duplicate those None-like semantics within the class. The distinction you make between user-defined and non-user-defined classes doesn't hold water. If you allow that (say) `int|None` **might** be acceptable, then why would `Integer|None` **necessarily** be lazy and bad just because int is written in C and built into the intepreter while Integer is written in Python by a user? The laziness/badness of `SomeType|None` must depend on the semantics of SomeType, not the implementation language or who wrote it. "Our API was lazy and bad because it uses None, but then it got accepted into Python as a builtin, so now it is no longer lazy or bad." /s Of course people can write None-like instances of their SomeType classes, if it makes sense for their application. But the idea that any and every use (or even a majority) of Optional types is a "lazy/bad API" is, I think, unrealistic puritism, not to mention unfairly disparaging towards the programmers who write those APIs.
The problem is, that I never actually thought about his suggested way.
Some people have, and found that it doesn't always simplify the API that much, or at all. If you end up replacing `obj is None` with `obj == NULL` or `obj.isnull()` then you haven't really gained much. -- Steven