Passing in None-type object and not marking it as a reportArgumentType error for Pythonnet

[zarif98]

So I generated some stubs from my C# DLLs that have a certain type within their methods. So in C#, you can pass in null for anything but in Python you'll get with a None-type error. Is it possible for Pyright to ignore "reportArgumentType" when a method is sending in None for their parameters?

[erictraut]

Converting to a discussion topic since this isn't a bug report.

[erictraut]

I'm not sure I understand what you're asking. Could you provide a concrete code sample?

Pyright's type checking behaviors are dictated to a large extent by the Python typing spec, so the answer to your question is likely "no".

If your intent is to accept None for every parameter, then they should be annotated with a union that includes None.

[zarif98]

So we interface with our C# code since that is the majority of our codebase. Our main issue is that when we generate the stubs for our DLLs with all of its classes we usually get the type of object in relation as well. In C# you can pass something as null for a parameter but in Python it makes it a None-type object which clashes with type of object that the stub parser generated.

This is the error that we end up getting:

Pythonnet converts None to null and allows it to pass through our C# code which makes it okay for us to run the code when interfacing with our C# code. Is it possible to make changes to Pyright where if it sees a None, it doesn't mark it as an error? I can make it so that all stubs are also optionally None as well but would like to have it where our checker can handle something like this for our code.

[erictraut]

Is it possible to make changes to Pyright where if it sees a None, it doesn't mark it as an error

That would violate the Python typing spec, so that's not something we'd include in pyright. Of course, pyright is open-sourced, so you're free to modify the code and build your own private version.

If you want all of your functions to accept values of None, I recommend updating your stubs to reflect that. For example, if you want a function to accept either AffineTransform or None, then change the type annotation to AffineTransform | None.

[zarif98]

Implemented that change but if someone wanted to make Pyright match the stubs and also allow for a None option. Where would one make that change for the parser? Asking for a friend haha

[erictraut]

If your stubs accurately reflect the types you want pyright to enforce, then there's no need to modify pyright. Regardless, there is no need to modify pyright's parser unless you're deviating from the standard Python grammar.