Jean-Paul Calderone <exar...@twistedmatrix.com> writes:
On Thu, Apr 25, 2019 at 12:52 PM Jean-Paul Calderone <
exar...@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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
