On Sep 15, 2006, at 7:04 PM, Jim Jewett wrote:
On 9/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:Jim Jewett wrote:... would be necessary to at least *scan* the string when itwas first created in order to ensure it can be decoded without errorsWhat happens today with strings? I think the answer is: "Nothing. They print something odd when printed. They may raise errors when explicitly recoded to unicde." Why is this a problem?We don't have 8-bit strings lying around in Py3k.Right. But we do in Py 2.x, and the equivalent delayed errors have not been a serious problem. I suppose that might change if everyone were actually using unicode, so that more stuff got converted eventually. On the other hand, I'm not sure how many strings will *ever* need recoding, if we don't do it on construction.
Automatic conversion from str to unicode in Py2.x is a annoying at times, mostly because it is easy to mis at development time. Using unicode throughout (explicit conversion to unicode at the application boundary) solves that, but that problem would reappear if unicode (somestr, someencoding) would return a value that might cause a when you try to access its value UnicodeError.
Another reason for disliking your idea is that unicode/py3k-str is a sequence of unicode code points and should always behave like one to the user. A polymorphic string type is an optimization (and an unproven one at that) and shouldn't complicate the Python-level string API.
Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
