[Python-Dev] Allowing Unicode literals even without Unicode support?

[Guido van Rossum]

> 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
the sizes:

   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"
type.)

--Guido van Rossum (home page: http://www.python.org/~guido/)