> Martin, if you're going to stick with the half-surrogate trick, would > you mind adding a section to the PEP on "alternate encoding strategies", > explaining why the NULL method was not selected?
In the PEP process, it isn't my job to criticize competing proposals. Instead, proponents of competing proposals should write alternative PEPs, which then get criticized on their own. As the PEP author, I would have to collect the objections to the PEP in the PEP, which I did; I'm not convinced that I would have to also collect all alternative proposals that people come up with in the PEP (except when they are in fact amendments that I accept). I hope I had made it clear that I don't try to "shoot down" alternative proposals, but have rather asked people making alternative proposals to write their own PEPs. At some point (when the amount of alternative proposals grew unreasonably), I stopped responding to each and every alternative proposal that this should be proposed in a separate PEP. Wrt. escaping with U+0000: I personally disliked it because I considered it difficult to implement. In particular, on encoding: how do you arrange the encoder not to encode the NUL character in the encoding, as it would surely be a valid character? The surrogate approach works much better here, as it will automatically invoke the error handler. With further testing, I found that in practice, the proposal also suffers from the problem that the character would be taken as a terminating character by APIs - I found that to be a real problem in gtk, and have added that to the PEP. Regards, Martin _______________________________________________ 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