typing: Handling of arguments that can be None

[Philippe Fremy]

Hi,

Le 14/07/2023 à 14:30, Phil Thompson a écrit :
>
> SIP wasn't generating 'Optional' when it should - now fixed. However, 
> as I said above, the default behaviour is for SIP to allow None to be 
> used and passed as NULL so while the behaviour of PyQt hasn't changed, 
> the user might now assume that None is a valid value to pass (because 
> the help and type hints say it is allowed) even though it's a bad idea.

This is the right choice. Qt deals very well with NULL pointers passed 
everywhere where a pointer is expected. Sometimes it is documented, 
sometimes it makes sense in API usage eventhough not documented, and in 
the worst case, the method call will do nothing and/or return a kind of 
error or empty.

As someone who has worked extensively on the PyQt stubs, my opinion is 
that it makes no sense to try to infer where None could be allowed. None 
should basically be accepted everywhere a pointer is accepted, this is 
the real behavior of PyQt and Qt. And the typing stubs should reflect 
that with Optional.

I have yet to see a case where passing None could create a problem and 
should be reflected in the stubs.

>
> The solution, using the current SIP, is to use the /DisallowNone/ 
> annotation wherever None is a bad idea. However if, as you suggest, 
> this is the majority of cases then it might be better to add a global 
> option to switch the default to disallow None and only annotate the 
> relatively few cases that it is allowed.

I disagree with Florian here. Current behavior is just right.

Regards,

Philippe