Tim Peters wrote: > [Tim] > >>>I don't know why Martin favors wchar_t when possible. The answer to >>>that isn't clear. > > [Martin v. Löwis] > >>If the wchar_t is "usable", some routines (notably PU_AsWideChar) are >>slightly more efficient, so I'd like to make wchar_t "usable" as much >>as possible. > > OK. So is there an end to this thread <0.9 wink>? At the moment, it > appears there's no identified reason to care about signedness of a > greater-than 16-bit type, Sure there is: first of all, having a single type that can be signed on some platforms and unsigned on others is a bad thing per se and second the 32-bit signed wchar_t value was what triggered this thread in the first place. > good reason to insist that a 16-bit type is > unsigned, and that it's desirable for HAVE_USABLE_WCHAR_T to get defined > when possible. What more does it take to bury this? If it's Unixish config > chagnes, they won't be coming from me (the Windows build uses an unsigned > 16-bit wchar_t). That's what it takes, right. I'll work on it. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Sep 22 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
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