Nick Coghlan wrote:
The mini-language parser has to assume in encoding in order to interpret the format string, and that's *all* done assuming an ASCII compatible format string (which must make life interesting if you try to use an ASCII incompatible coding cookie for your source code
I don't think it's all *that* interesting. As long as you're able to type the relevant characters on your keyboard and have them displayed in a recognisable way in your editor, then what looks like b"Content-Length: %d" in your source will end up encoded as ascii in the bytes object, whatever the encoding of the source file. If the source file uses an encoding that can't even represent the formatting characters, then you're in trouble -- but you'd have a hard time writing Python code at all in such an environment!
It's certainly a decision that has its downsides, with the potential impact on users of ASCII incompatible encodings (mostly in Asia) being the main one,
I don't think it will have much impact on them, other than maybe they will find less use cases for it. But the main intended use cases are for things like http headers which have protocol-mandated ascii-ish bits, and those bits are still just as ascii-ish in China as they are anywhere else. -- Greg _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
