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>
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