On 26 August 2011 17:51, Guido van Rossum <gu...@python.org> wrote: > On Fri, Aug 26, 2011 at 2:29 AM, "Martin v. Löwis" <mar...@v.loewis.de> wrote:
(Regarding my comments on code point semantics) >> You seem to assume it is ok for Jython/IronPython to provide indexing in >> O(n). It is not. > > Indeed. On 26 August 2011 18:02, Guido van Rossum <gu...@python.org> wrote: > Eek. No, please. Those platforms' native string types have length and > slicing operations that are O(1) and work in terms of 16-bit code > points. Python should use those. It would be awful if Java and Python > code doing the same manipulations on the same string would come to > different conclusions because Python tried to paper over surrogates. *That* is actually the erroneous assumption I had made - that the Java and .NET native string type had code point semantics (i.e., took surrogates into account). As that isn't the case, my comments aren't valid - and I agree that having common semantics (and hence exposing surrogates) is too important to lose. On the other hand, that pretty much establishes that whatever PEP 393 achieves in terms of allowing all builds of CPython to offer code point semantics, the language definition can't mandate it. Thanks for the clarification. Paul. _______________________________________________ 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
