[Python-Dev] PEP 393 review (original) (raw)

Stefan Behnel stefan_ml at behnel.de
Fri Aug 26 21:58:52 CEST 2011

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 PyUnicodeReady 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 PyUnicodeReady() 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 PyUnicodeFASTREADY() 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 PyUnicodeReady() calls get removed, PyUnicodeKIND() could take that place by simply returning WSTRKIND.

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>

More information about the Python-Dev mailing list