pyright has trouble understanding cffi interfaces

[adsharma]

Sample code

src/stdlib/re.py:51:21 - error: Cannot access attribute "free" for class "Lib"

Can it infer the types based on cffi's cdefs? Looking for advice here to get good type safety without many type ignores.

[adsharma]

Also getting:

# error: Type "bytes | str" is not assignable to declared type "bytes"
result_bytes: bytes = ffi.string(result)

What's a good way to handle this? In my case result is always a const char *

[erictraut]

Pyright has no special knowledge of third-party libraries like cffi in your example. Pyright performs its analysis based on the type information provided to it and the type validation rules spelled out in the Python typing spec. If you suspect that pyright is applying these rules incorrectly, please file a bug report with a minimal, self-contained code sample that demonstrates the problem.

I'm not familiar with the cffi library, so if you have specific questions about its usage, you may want to post a question in a forum specific to that library.

As for your second question, the type bytes | str is wider than the type bytes, so it isn't legal to assign a value of type bytes | str to a variable that is declared to accept only bytes. I don't have enough context about your use case to suggest the best way to address this in your code. Some options include:

1. Use a typing.cast call to cast the type of the RHS expression to the desired type.

   cast(bytes, ffi.string(result))

2. Use an assert statement:

   temp = ffi.string(result)
   assert isinstance(result, bytes)
   result_bytes: bytes = temp

[adsharma]

Thanks. The casts fixed one class of problems.

I have type stubs here. But I'm unable to figure out where/how pyright looks for the stubs.

The native code is loaded via:

lib = ffi.dlopen(some_dynamically_constructed_path)

[erictraut]

For information about stubs, refer to this section of the Python typing spec. You can also find information in the pyright documentation here.

Take care when using cast. You're effectively overriding the type checker. This can mask real bugs when you refactor your code in the future. An assert is preferable because your assumptions are validated at runtime by the assertion check.

[adsharma]

The reason why I chose casts over asserts is that the goal of the effort is to transpile python to other languages such as Rust/C++. There will be no runtime asserts in those cases and hopefully ffi.string() will be transpiled to something that has a more predictable typing.

Thanks for the pointer to the typing doc. I'll share a solution here if I can find one.