[MAL] > 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. pymalloc would improve both, so I'd much rather pursue that in 2.3 than yet another type-specific free list. > 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 :-) Most of us have machines between those extremes, and the difference between 100MB and 300MB can be make-or-break. I don't see that any "flexibility" is gained merely by wasting memory <wink>. > ... > Any idea how we could make subclassing these types less > hackish, then ? Subclassing seems easy enough to me from the Python level; I don't have time to revisit C-level subclasssing here (and I don't know that it's hackish there either, but do think it's in need of docs).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4