|
|
Log in / Subscribe / Register

Report from the Python Language Summit

Report from the Python Language Summit

Posted Apr 16, 2015 22:38 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Report from the Python Language Summit by flussence
Parent article: Report from the Python Language Summit

> It is, but I'd say because nobody has a clue how to define "char". It can mean all sorts of things depending on where it's used
Correct. And complex scripts or complex characters make it even more complicated.

That's why I violently oppose the definition: "UCS-4 codepoint is a character or GTFO", which Python3 tries to enforce.


to post comments

Report from the Python Language Summit

Posted Apr 21, 2015 22:31 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Python says that its internal encoding is Unicode, but the nice thing about the enforced mapping to bytes to get it out anywhere else is that good code need not rely on this at all. As long as you always transcode to/from bytes when leaving the Python world, you can *completely ignore* what internal encoding the thing is using (or, rather, use the Unicode stuff like properties etc as needed inside your code, in the happy knowledge that this will not affect transfer to external systems at all, no matter what encoding they use, as long as a codec exists. And writing codecs is *really* not hard, at least not if you don't care much about performance, e.g. for one-off mappings where no codec exists in Python yet :) )

Report from the Python Language Summit

Posted Apr 21, 2015 23:06 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

A couple of times I had to resort to hacks like putting raw bytes into the LSB of UCS-4 codepoints.

I still think that treating strings as sequences of UTF-8 characters and/or bytes is the best possible way. Enforced UCS-4 rarely helps.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds