[Python-Dev] Subclassing varying length types (What's a
Sat, 01 Dec 2001 12:27:20 +0100
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 ?
CEO eGenix.com Software GmbH
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/