A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-January/107707.html below:

[Python-Dev] PEP 393: Flexible String Representation

[Python-Dev] PEP 393: Flexible String Representation [Python-Dev] PEP 393: Flexible String RepresentationAntoine Pitrou solipsis at pitrou.net
Thu Jan 27 15:57:18 CET 2011
Le mercredi 26 janvier 2011 à 21:50 -0800, Gregory P. Smith a écrit :
> >
> > Incidentally, to slightly reduce the overhead the unicode objects,
> > there's this proposal: http://bugs.python.org/issue1943
> 
> Interesting.  But that aims more at cpu performance than memory
> overhead.  What I see is programs that predominantly process ascii
> data yet waste memory on a 2-4x data explosion of the internal
> representation.  This PEP aims to address that larger target.

Right, but we should keep in mind that many unicode strings will not be
very large, and so the constant overhead of unicode objects is not
necessarily negligible.

Regards

Antoine.


More information about the Python-Dev mailing list

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