As best I can tell, some people (apparently including Guido
and PEP author Antoine) are taking some assumptions almost
for granted, while other people (including me, before Nick's
messages) were not assuming them at all.
Since these assumptions (or, possibly, rejections of them?)
are likely to decide the outcome, the assumptions should be
explicit in the PEP.
(1) The bytes-related classes do include methods that
are only useful when the already-contained data
is encoded ASCII.
They do not (and will not) include any operations
that *require* an encoding assumption. This
implies that no non-bytes data can be added without
an explicit encoding.
(1a) Not even by assuming ASCII with strict error handling.
(1b) Not even for numbers, where ASCII/strict really is
sufficient.
Note that this doesn't rule out a solution where objects
(or maybe just numbers and ASCII-kind text) provide their own
encoding to bytes -- but that has to be done by the objects
themselves, not by the bytes container or by the interpreter.
(2) Most python programmers are still in the future.
So an API that confuses people who are still learning
about Unicode and the text model is bad -- even if it
would work fine for those who do already understand it.
-jJ
--
If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them. -jJ
_______________________________________________
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
