> On Nov 22, 2016, at 21:36, Mark Williams <markrwilli...@gmail.com> wrote:
> 
> 
> 
> On Tuesday, November 22, 2016, Glyph Lefkowitz <gl...@twistedmatrix.com 
> <mailto:gl...@twistedmatrix.com>> wrote:
> 
> Okay.  So.
> 
> 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:
> 
> https://github.com/buildbot/buildbot/blob/40d5dd3d101704aa8db582e306b3c6cf7921c23c/master/buildbot/reporters/irc.py#L67-L68
>  
> <https://github.com/buildbot/buildbot/blob/40d5dd3d101704aa8db582e306b3c6cf7921c23c/master/buildbot/reporters/irc.py#L67-L68>
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.

-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Reply via email to