[Twisted-Python] Backward incompatible fixes to backward incompatible changes

[Evilham]

Jean-Paul Calderone <exarkun at twistedmatrix.com> writes:

> On Thu, Apr 25, 2019 at 12:52 PM Jean-Paul Calderone <
> exarkun at twistedmatrix.com> wrote:
>
>> Hello all,
>>
>> I'd like to discuss the project policy/process for dealing with 
>> incorrect
>> backward incompatibilities that end up released.
>>
>
> Considering the lack of interest in the topic, I'm going to 
> suppose that
> there is no policy and the decision is made case-by-case.  In 
> the case I
> referenced, I'm going to approve the change in behavior as 
> "compatible" by
> on the grounds that it restores the original behavior.


What you say makes sense and, as read on one of the tickets, if 
there *is* a need for that situation to raise an error: 
`AttributeError` certainly isn't the kind of error.
So that should be a totally different discussion.

As for a general policy: it doesn't look like this situation 
happens often enough for there to be a need for one (de facto, 
indeed that means that it is made on a case-by-case basis).
Effort in general should be to prevent the situation from 
happening, which everyone regularly involved in Twisted does a 
great job at already.

Basically: ACK, fully agreed, you are not talking to the void.

>> As a case study, we could look at
>> https://twistedmatrix.com/trac/ticket/9410
>> <https://twistedmatrix.com/trac/ticket/9410#comment:17> /
>> https://github.com/twisted/twisted/pull/1106
>>
>> In Twisted 16.3.0 the behavior of Request.write was changed so 
>> that it
>> raises an AttributeError if called after the connection has 
>> closed.  Prior
>> to that release, it silently did nothing in that case.
>>
>> Now, three years later, we have a PR which proposed restoring 
>> the behavior
>> of silently ignoring the write to a closed connection.
>>
>> The original change was incompatible.  The new change is 
>> incompatible.
>> What should win out?

--
Evilham