Fredrik Lundh wrote: > > mal wrote: > > > - compact the unicodedata database, which is expected to reduce the > > > mem footprint, maybe improve startup time, etc. (ongoing) > > > > This was postponed to 2.1. It doesn't have any impact on > > performance... > > sure has, for anyone distributing python applications. we're > talking more than 1 meg of extra binary bloat (over 2.5 megs > of extra source code...) Yes, but not there's no impact on speed and that's what Valdimir was referring to. > the 2.0 release PEP says: > > Compression of Unicode database - Fredrik Lundh > SF Patch 100899 > At least for 2.0b1. May be included in 2.0 as a bug fix. > > (the API is frozen, and we have an extensive test suite...) Note that I want to redesign the Unicode database and ctype access for 2.1: all databases should be accessible through the unicodedatabase module which will be rewritten as Python module. The real data will then go into auxilliary C modules as static C data which are managed by the Python module and loaded on demand. This means that what now is unicodedatabase will then move into some _unicodedb module. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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