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

Reply via email to