Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ctypes stubs incomplete #475

Closed
gvanrossum opened this issue Aug 16, 2016 · 9 comments
Closed

ctypes stubs incomplete #475

gvanrossum opened this issue Aug 16, 2016 · 9 comments

Comments

@gvanrossum
Copy link
Member

Sadly #454 leaves our code using ctypes a bunch of errors, not all of which are our fault. A few examples:

  • wintypes.pyi is empty?!
  • offset in from_buffer_copy() is optional
  • apparently c_char*16 is valid to declare a 16-byte buffer
@gvanrossum gvanrossum mentioned this issue Aug 16, 2016
@euresti
Copy link
Contributor

euresti commented Aug 22, 2016

Couple of others:

  • offset in from_buffer is optional
  • As typed from_buffer and from_buffer_copy expect _CData as first argument
  • from_buffer and from_buffer_copy return _CData instead of the class that is being created.
    (e.g.
 from ctypes import Structure, c_ulong, c_ushort

class POINT(Structure):
   _fields_ = [(u"x", c_ulong),
               (u"y", c_ulong),
               ]

p = POINT()

buf = bytearray(b'\00' * 8 + b'\01' + b'\00' * 7)
p2 = POINT.from_buffer_copy(buf)

reveal_type(p)    # Point
reveal_type(p2)  # _CData
  • The attributes of Structure can't be accessed. So in the above p.x yields a type error.

@gvanrossum
Copy link
Member Author

Fixing the return type of from_buffer()/from_buffer_copy() would require fixing python/mypy#1212; I think I'll use Any for now. This isn't great, but that bug is pretty subtle. Most other things are doable.

@gvanrossum
Copy link
Member Author

Fixing c_char*16 is also problematic, because c_char is a class! The __mul__ operation is overloaded on the metaclass. But mypy doesn't support that yet. I think that's another case of python/mypy#1267.

@gvanrossum
Copy link
Member Author

@matthiaskramm @tharvik How bad would it be if I just reverted #454? There's no way I can get our internal usages of ctypes to pass without fixing some tricky mypy issues (see previous comments). Putting # type: ignore in the stub won't be possible for these -- we'd have to ignore each call site of those features.

@tharvik
Copy link
Contributor

tharvik commented Aug 24, 2016

wintypes.pyi is empty?!

It is not documented and only available on Windows (which I don't have).

Fixing c_char*16 is also problematic, because c_char is a class!

I found a way by using (not pretty, but working)

class _MulType(Generic[_T]):
    def __call__(self, *args: Any, **kwargs: Any) -> _T: ...
    def __mul__(self, size: int) -> _MulType[_T]: ...

c_int = ...  # type: _MulType[_SimpleCData[int]]

@gvanrossum I guess we can revert it but keep this issue open to have a remainder to do something when mypy is fixed.

@gvanrossum
Copy link
Member Author

I've deleted the ctypes stub for now. After mypy 0.4.4 has been released (tomorrow?) I'll try to restore the previous version and improve it to the point where our internal code can pass with it.

@JukkaL
Copy link
Contributor

JukkaL commented Aug 24, 2016

There's also the option of annotation c_char with type Any. Again, not optimal, but some type checking is better than nothing.

@gvanrossum
Copy link
Member Author

I think @tharvik's solution can be made to work, I just don't want to do it so close to the 0.4.4 release.

@JelleZijlstra
Copy link
Member

We have pretty good ctypes stubs now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants