> >> BTW, a sane collection of typedefs would be another good candidate for > >> pyport.h. > > [M.-A. Lemburg] > > Good idea. > > > > The only problem with typedefs is that they tend to cause conflicts > > when different definitions are encountered. > > We'd have to use e.g. Py_UINT4, Py_UINT2, etc... > > Yes, but that's a hell of a lot better than the path the patch in question > started going down, w/ its Unicode-specific _PyUnicode_Int32 and (! probably > a bug) _PyUNICODE_Int32. C already *has* a sane collection of typedefs: short, int, long, maybe combined with unsigned. Plus size_t and so on. There should be only relatively few places where these aren't sufficient: the most common case being when you need the smallest type that's at least 32 bits, which on some systems is spelled as long, on others as int. When you need exactly 32 bits, you're out of luck (e.g. on Crays, it seems, if Tim is right). So it would be better not to write code that depends on exactly 32 (or 16, or 64, or 27) bits. Places where you just *have* to have exactly 32 bits are rare -- perhaps the calculation of 32-bit checksums is commonly done this way, but even there I would expect that it's possible to write the code to be correct for larger int sizes as well. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
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