> On Jun 9, 2016, at 11:11 PM, Larry Hastings <la...@hastings.org> wrote:
> 
> I don't understand why so many people seem to think it's okay to break old 
> code in new versions of Python, when Python's history has shown a similarly 
> strong commitment to backwards-compatibility.


Python *regularly* breaks compatibility in X.Y+1 releases, and does it on 
purpose. An example from Python 3.5 would be PEP 479. I think breaking 
compatibility is a good thing from time to time, as long as it’s not done so 
with wanton disregard and as long as the cost is carefully weighed against the 
benefits.

One of the more frustrating aspects of trying to discuss security sensitive 
topics on python-dev is a feeling (at least from my end) that whenever someone 
wants to make something more secure [1] folks come in and try to anchor the 
discussion by treating backwards compatibility as some sort of sacred duty that 
can never be broken and the discussion ends up feeling (from the security side 
that I’m typically on) being try to justify the idea of ever breaking backwards 
compatibility, instead of weighing the cost/benefit of a particular change. On 
the flip side, when a different kind of change that breaks compatibility , say 
to make some behavior less confusing, gets brought up it feels like the 
discussion instead focuses on whether or not breaking compatibility is worth it 
in that particular instance.

I’m perfectly happy to accept that Python has decided to make a trade off 
differently than what I would prefer it, but the rhetoric that is employed 
makes trying to improve Python’s security an extremely frustrating experience 
for myself and others [2]. Feeling like you have to litigate that it’s *ever* 
OK to break compatibility before you can even get to the point of discussing if 
it makes sense in any particular instance, while watching other kinds proposals 
not have to do that is a pretty disheartening experience.


[1] Making code more secure pretty much by definition means taking some code 
that previously executed and making it so it no longer executes, ideally only 
in degenerate and dangerous conditions, but in general, that’s always the case.

[2] I don’t want to name names, as they didn’t give me permission to do so, but 
these discussions have caused more than one person who tends to fall on the 
security side of things to consider avoiding contributing to Python at all, 
because of this kind of rhetoric.

—
Donald Stufft



_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to