Tim Peters wrote: > > [posted & mailed] > > [Jack Jansen] > > Is anyone else experiencing problems with the immense new switch in > > unicodectype.c? Trying to compile it crashes my machine(!)... > > No problem here, but it needs to be fixed for you! There's no future in > pushing anyone's compiler limits, and particularly not when Python is > attracting more attention on smaller platforms (read feebler compilers, > among others gotchas). > > I believe we also need a way to split unicodedatabase.c into multiple files, > as > 64K lines in a source file is unreasonable (Python can't handle a > source file that large either, and Python is the *definition* of > reasonableness here <wink>), and the MS compiler spits out a warning about > its sheer size. > > Or was Christian's long-threatened compression patch supposed to reduce the > line count in that one? Both the line count and the memory consumption... the same can be done for unicodectype.c -- but I don't have the time to look into this, so for now all I can offer is to split the huge switch in two if that helps. BTW, if your compiler supports Unicode (that is provides a working wctype.h file), you can compile Python using the compile time switch --with-wctype-functions. Python will then use the C libs iswXXX() APIs which should return more or less the same values as the Python ones (could be that the C lib is Unicode 2.0 -- so YMMV). Note that this hasn't been tested much yet. Feedback is welcome. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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