Tim Peters wrote:
[M.-A. Lemburg]
... Hmm, this makes me wonder: perhaps we should start thinking about phasing out varying length PyObjects in the interpreter...
No chance, IMO: the memory savings is too great.
esp. the inability to subclass strings looks like a bummer for future extensions of this particular type. Unicode doesn't have this problem, BTW.
OTOH, I know someone at Zope Corp who could testify with force about the memory burden of switching to Unicode strings -- if you've got gobs of 'em, it's much worse than a factor of 2 blowup. Moving to obmalloc.c should help that a lot (two malloc overheads per Unicode string, and obmalloc overheads are much lower).
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. 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 :-)
Or we need to come up with a fairly nice way of making subclassing varying length types a lot easier, e.g. by adding a special pointer ob_ext to PyObject_VAR_HEAD which then allows declaring type extensions in an malloced buffer.
Thoughts ?
Not a one <wink>.
Any idea how we could make subclassing these types less hackish, then ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/