[Twisted-Python] Twisted 16.6.0rc1 Release Candidate Announcement

[Glyph Lefkowitz]

> On Nov 22, 2016, at 21:36, Mark Williams <markrwilliams at gmail.com> wrote:
> 
> 
> 
> On Tuesday, November 22, 2016, Glyph Lefkowitz <glyph at twistedmatrix.com <mailto:glyph at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20161123/5918ff81/attachment-0002.html>