Guido van Rossum wrote:
> All in all, given the advantage (half the number of allocations) of
> the proposal I think there would have to be *very* good arguments
> against before we reject this outright. I'd like to understand
> Marc-Andre's reasons too.
As Stefan notes, because of the frequency with which strings are
manipulated in C code via PyString_* / PyUnicode_* calls, it is a data
type where "accept no substitutes" prevails.
MAL's primary concern appears to be that having Unicode as a plain
PyObject leaves the type more open to subclass-based optimisations that
have been rejected for the builtin types themselves. Having
PyString/PyBytes as PyVarObjects means that subclasses are more limited
in what they can do.
One possibility that occurs to me is to use a PyVarObject variant that
allocates space for an additional void pointer before the variable sized
section of the object. The builtin type would leave that pointer NULL,
but subtypes could perform the second allocation needed to populate it.
The question is whether the 4-8 bytes wasted per object would be worth
the fact that only one memory allocation would be needed.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
