Message88307
Antoine, I have explained the reasons for rejecting the patch. In short,
it violates a design principle behind the Unicode implementation.
If you want to change such a basic aspect of the Unicode implementation,
then write a PEP which demonstrates the usefulness on a larger set of
more general tests and comes up with significant results (10% speedup in
some micro benchmarks is not significant; memory tests need to be run
without pymalloc and require extra care to work around OS malloc
optimization strategies).
Like I said: The current design of the Unicode object implementation
would benefit more from advances in pymalloc tuning, not from making it
next to impossible to extend the Unicode objects to e.g.
* reuse existing memory blocks for allocation,
* pointing straight into memory mapped files,
* providing highly efficient ways to tokenize Unicode data,
* sharing of data between Unicode objects,
etc.
The reason I chose this design was to make the above easily
implementable and it was a conscious decision to use a PyObject
rather than a PyVarObject, like the string object, since I knew
that the Unicode object was eventually going to replace the string
object. |
|
Date |
User |
Action |
Args |
2009-05-25 08:17:56 | lemburg | set | recipients:
+ lemburg, collinwinter, jafo, amaury.forgeotdarc, pitrou, vstinner, ajaksu2, orivej, ezio.melotti |
2009-05-25 08:17:56 | lemburg | set | messageid: <1243239476.41.0.694089874892.issue1943@psf.upfronthosting.co.za> |
2009-05-25 08:17:55 | lemburg | link | issue1943 messages |
2009-05-25 08:17:54 | lemburg | create | |
|