Message88307
| Author |
lemburg |
| Recipients |
ajaksu2, amaury.forgeotdarc, collinwinter, ezio.melotti, jafo, lemburg, orivej, pitrou, vstinner |
| Date |
2009年05月25日.08:17:53 |
| SpamBayes Score |
3.4527936e-13 |
| Marked as misclassified |
No |
| Message-id |
<1243239476.41.0.694089874892.issue1943@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|