Stefan Behnel, 03.03.2013 20:41: > Nikita Nemkin, 03.03.2013 14:40: >> Please reconsider your decision wrt C-level literals. >> I believe that nogil code and a bit of efficiency (on 3.3) justify their >> existence. (char* literals do have C-level literals, Py_UNICODE* is in >> the same basket when it comes to Windows code). >> The code to support them is also small and well-contained. >> I've updated my pull request to fully support for non-BMP Py_UNICODE[] >> literals. > > Ok, I think it's ok now. I can accept the special casing of Py_UNICODE > literals, it actually adds a value. > > As one little nit-pick, may I ask you to rename the new name references to > "unicode" into "py_unicode" in your code? For example, "is_unicode", > "get_unicode_const", "unicode_const_index", etc. Given that Py_UNICODE is > no longer the native equivalent of Python's unicode type in Py3.3, I'd like > to avoid confusion in the code. The name "unicode" is much more likely to > refer to the builtin Python type than to a native C type when it appears in > Cython's sources.
Oh, and yet another thing: could you write up some documentation for this in docs/src/tutorial/strings.rst ? Basically a Windows/wchar_t related section, that also warns about the inefficiency in Py3.3, so that users don't accidentally assume it's efficient for anything that needs to be portable. Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel