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
_______________________________________________
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/C4GJX5O7FX2WBZMJ6DU5PVI5LUV5NCT5/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to