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

[Python-Dev] PEP 393: Flexible String Representation

[Python-Dev] PEP 393: Flexible String Representation [Python-Dev] PEP 393: Flexible String Representation"Martin v. Löwis" martin at v.loewis.de
Fri Jan 28 01:02:32 CET 2011
Am 27.01.2011 23:53, schrieb Stefan Behnel:
> "Martin v. Löwis", 24.01.2011 21:17:
>> If the string is created directly with the canonical representation
>> (see below), this representation doesn't take a separate memory block,
>> but is allocated right after the PyUnicodeObject struct.
> 
> Does this mean it's supposed to become a PyVarObject?

What do you mean by "become"? Will it be declared as such? No.

> Antoine proposed
> that, too. Apart from breaking (more or less) all existing C subtyping
> code, this will also make it harder to subtype it in new code. I don't
> like that idea at all.

Why will it break all existing subtyping code? See the PEP: Only objects
created through PyUnicode_New will be affected - I don't think this can
include objects of a subtype.

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