[Python-Dev] Allowing Unicode literals even without Unicode support?
Guido van Rossum
Mon, 27 May 2002 10:00:07 -0400
> People have requested this because they were shocked of the increase
> in size of the Python interpreter, which primarily originates from the
> Unicode character database. While I think people would get over their
> shock as time passes, I think creating a "small" interpreter for
> special-purpose applications is desirable, and just deleting Unicode
> support in such a build was (and still is) a low-hanging fruit.
I wanted to make a gesture towards the developers of the PalmOS port
(Pippy), who have struggled mightily to keep memory usage small. But
nothing is happening there (I've asked them to make it a SF project
but apparently Endeavors Technology refuses).
I think the iPAQ has enough memory to support Unicode, and that's the
only small platform I'm aware of that uses Python. Of course, there
are probably other embedded platforms -- but they have to speak up.
BTW, the savings aren't that big. I built Python with all the
configure options disabled that I could find (hm, there's no way to
disable complex from the command line so that's still in) and here are
text data bss dec hex filename (file size)
531629 92336 9804 633769 9aba9 small_python (1904k)
613718 117588 11612 742918 b5606 python (2168k)
> That said, I see no reason why the test suite should pass in such a
> build. I would suggest to let this code rot (as long as you can still
> build the interpreter without Unicode), and wait for users to complain
> that features don't work in disable-unicode builds that they think
> should work.
I don't think the tests have to pass. But I do think that importing a
module and using its basic functionality should work, unless perhaps
it is designed to work only with Unicode (like the XML modules). The
email package violates this: Charset.py starts with "from types import
UnicodeType" and it is in turn imported by the basic Message module.
> Maybe we can take this feature out in P3k when we find that nobody
> uses it. Until then, I would propose to leave it roughly at the state
> of WITHOUT_COMPLEX. Does anybody know whether the test suite passes if
> you build WITHOUT_COMPLEX?
Dunno, but there's much less code affected. (Although, like unicode,
I know of some unittests that use complex as an example of a "weird"
--Guido van Rossum (home page: http://www.python.org/~guido/)