Message88779
| Author |
gvanrossum |
| Recipients |
ajaksu2, amaury.forgeotdarc, collinwinter, eric.smith, ezio.melotti, gvanrossum, jafo, jimjjewett, lemburg, orivej, pitrou, rhettinger, vstinner |
| Date |
2009年06月02日.23:51:45 |
| SpamBayes Score |
1.3892115e-07 |
| Marked as misclassified |
No |
| Message-id |
<1243986707.72.0.514977063082.issue1943@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
That's unfortunate; it would clearly have been easier to change this in 3.1.
That said, I'm not sure anyone *should* be subclassing PyUnicode. Maybe
Marc-Andre can explain why he is doing this (or point to the message in
this thread where he explained this before)? If it's a viable use case,
it should be possible to have some symbol or a few symbols whose
presence can be tested in the preprocessor by code that needs to
subclass; we should design the patch with that in mind and Marc-Andre
could help testing it.
All this is assuming the speed-up is important enough to bother. Has
anyone run a comparison benchmark using the Unladen Swallow benchmarks?
I trust those much more than micro-benchmarks (including, I assume,
stringbench.py). I do expect that reducing the number of allocations
for short-to-medium-size strings from 2 to 1 would be a significant
speed-up, but I can't guess how much. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2009年06月02日 23:51:47 | gvanrossum | set | recipients:
+ gvanrossum, lemburg, collinwinter, rhettinger, jafo, jimjjewett, amaury.forgeotdarc, pitrou, vstinner, eric.smith, ajaksu2, orivej, ezio.melotti |
| 2009年06月02日 23:51:47 | gvanrossum | set | messageid: <1243986707.72.0.514977063082.issue1943@psf.upfronthosting.co.za> |
| 2009年06月02日 23:51:46 | gvanrossum | link | issue1943 messages |
| 2009年06月02日 23:51:45 | gvanrossum | create |
|