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/107713.html below:

[Python-Dev] PEP 393: Flexible String Representation

[Python-Dev] PEP 393: Flexible String Representation"Martin v. Löwis" martin at v.loewis.de
Thu Jan 27 22:05:38 CET 2011
> So, the only criticism I have, intuitively, is that the unicode
> structure seems to become a bit too large. For example, I'm not sure you
> need a generic (pointer, size) pair in addition to the
> representation-specific ones.

It's not really a generic pointer, but rather a variable-sized pointer.
It may not fit into any of the other representations (e.g. if there is
a four-byte wchar_t, then a two-byte representation would fit neither
into the UTF-8 pointer nor into the wchar_t pointer).

> Incidentally, to slightly reduce the overhead the unicode objects,
> there's this proposal: http://bugs.python.org/issue1943

I wonder what aspects of this patch and discussion should be integrated
into the PEP. The notion of allocating the memory in the same block is
already considered in the PEP; what else might be relevant?
Input is welcome!

Regards,
Martin
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