On 11/3/2011 5:43 PM, "Martin v. Löwis" wrote:
I had the impression that we were abolishing the wide versus narrow
build difference and that this issue would disappear. I must have missed
something.
Most certainly. The Py_UNICODE type continues to exist for backwards
compatibility. It is now always a typedef for wchar_t, which makes it
a 16-bit type on Windows.
Thank you for answering: My revised impression now is that any string I
create with Python code in Python 3.3+ (as distributed, without
extensions or ctypes calls) will use the new implementation and will
index and and slice correctly, even with extended chars. So indexing is
only an issue for those writing or using C-coded extensions with the old
unicode C-API on systems with a 16-bit wchar_t. Correct?
---
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
