[Python-Dev] PEP 393 review

[Stefan Behnel]

Stefan Behnel, 26.08.2011 20:28:
> "Martin v. Löwis", 26.08.2011 18:56:
>> I agree with your observation that somebody should be done about error
>> handling, and will update the PEP shortly. I propose that
>> PyUnicode_Ready should be explicitly called on input where raising an
>> exception is feasible. In contexts where it is not feasible (such
>> as reading a character, or reading the length or the kind), failing to
>> ready the string should cause a fatal error.
>[...]
> My gut feeling leans towards a KISS approach. If you go the route to
> require an explicit point for triggering PyUnicode_Ready() calls, why not
> just go all the way and make it completely explicit in *all* cases? I.e.
> remove all implicit calls from the macros and make it part of the new API
> semantics that users *must* call PyUnicode_FAST_READY() before doing
> anything with a new string data layout. Much fewer surprises.
>
> Note that there isn't currently an official macro way to figure out that
> the flexible string layout has not been initialised yet, i.e. that wstr is
> set but str is not. If the implicit PyUnicode_Ready() calls get removed,
> PyUnicode_KIND() could take that place by simply returning WSTR_KIND.

Here's a patch that updates only the header file, to make it clear what I mean.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simplified-pep-393-api.patch
Type: text/x-patch
Size: 4637 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110826/2cc927c1/attachment.bin>