Travis E. Oliphant schrieb: > I was too hasty. There are some things actually missing from ctypes: I think Thomas can correct me if I'm wrong: I think endianness is supported (although this support seems undocumented). There seems to be code that checks for the presence of a _byteswapped_ attribute on fields of a struct; presence of this field is then interpreted as data having the "other" endianness. > 1) long double (this is not the same across platforms, but it is a > data-type). That's indeed missing. > 2) complex-valued types (you might argue that it's just a 2-array of > floats, but you could say the same thing about int as an array of > bytes). The point is how do people interpret the data. Complex-valued > data-types are very common. It is one reason Fortran is still used by > scientists. Well, by the same reasoning, you could argue that pixel values (RGBA) are missing in the PEP. It's a convenience, sure, and it may also help interfacing with the platform's FORTRAN implementation - however, are you sure that NumPy's complex layout is consistent with the platform's C99 _Complex definition? > 3) Unicode characters > > 4) What about floating-point representations that are not IEEE 754 > 4-byte or 8-byte. Both of these are available in a platform-dependent way: if the platform uses non-IEEE754 formats for C float and C double, ctypes will interface with that just fine. It is actually vice versa: IEEE-754 4-byte and 8-byte is not supported in ctypes. Same for Unicode: the platform's wchar_t is supported (as you said), but not a platform-independent (say) 4-byte little-endian. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4