Perhaps we should start thinking about optimizing at least one of the Unicode malloc away in Python 2.3: the Unicode object itself can well be kept on a free list with the Py_UNICODE buffer freed and set to NULL. Doesn't save any memory but would improve the performance.
pymalloc would improve both, so I'd much rather pursue that in 2.3 than yet another type-specific free list.
BTW, is the memory burden really such a big argument these days ? I can imagine this being an argument on resource restrained platforms such as Palms (thanks to Martin, the Plam guys can now switch off Unicode completely), but hardly on gigabyte machines with access 100s of GBs swap-space :-)
Most of us have machines between those extremes, and the difference between 100MB and 300MB can be make-or-break. I don't see that any "flexibility" is gained merely by wasting memory <wink>.
... Any idea how we could make subclassing these types less hackish, then ?
Subclassing seems easy enough to me from the Python level; I don't have time to revisit C-level subclasssing here (and I don't know that it's hackish there either, but do think it's in need of docs).