On Nov 22, 2016, at 21:36, Mark Williams firstname.lastname@example.org wrote:
On Tuesday, November 22, 2016, Glyph Lefkowitz <email@example.com mailto:firstname.lastname@example.org> wrote:
The rule for reverts like this is: if you do something today, which is correct usage of the API and produces an observably correct result, will that be broken in the future if we fix it? If so, then we need to revert because the interface as released is unsupportable.
As it stands, we have a matrix of 4 behaviors:
bytes text(ascii) text(nonascii) py2 works works UnicodeDecodeError py3 garbage works works
This... is actually... fine, surprisingly.
Given that matrix, how would this work on Python 2 and 3:
It wouldn't work on Python 3 yet. But that's fine: the point is that it wouldn't work! Buildbot can just block porting on that bug.
And how would that code not have to change if a future release accommodates Unicode on Python 2 or bytes on Python 3?
Because it will get broken / undefined behavior on the current implementation. We can always fix broken behavior! What we can't do is fix broken behavior that also breaks other correct behavior or workarounds. But in this case, there's a broken behavior (which we have on trunk) and a correct behavior (which we can implement in the future) and no way to coerce the broken behavior to do something valid via public API.