jack wrote:
> > struct.pack("32s", wu(u"VS_VERSION_INFO"))
>
> Why would you have to specify the encoding if what you want is the normal,
> standard encoding?
because there is no such thing as a "normal, standard
encoding" for a unicode character, just like there's no
"normal, standard encoding" for an integer (big endian,
little endian?), a floating point number (ieee, vax, etc),
a screen coordinate, etc.
as soon as something gets too large to store in a byte,
there's always more than one obvious way to store it ;-)
> Or, to rephrase the question, why do C programmers only
> have to s/char/wchar_t/
because they're tend to prefer to quickly get the wrong
result? ;-)
C makes no guarantees about wchar_t, so Python's Unicode
type doesn't rely on it (it can use it, though: you can check
the HAVE_USABLE_WCHAR_T macro to see if it's the same
thing; see PyUnicode_FromWideChar for an example).
in the Mac case, it might be easiest to configure things so
that HAVE_USABLE_WCHAR_T is always true, and assume
that Py_UNICODE is the same thing as wchar_t. (checking
this in the module init function won't hurt, of course)
but you cannot rely on that if you're writing truly portable
code.
</F>
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