On Mon, Dec 30, 2013 at 10:43 PM, james <[email protected]> wrote: > As an occasional Python programmer who really prefers Python 3, I'd suggest > that the experience there is that breaking change is not straightforward to > deliver, > no matter how much goodness there is. > > Do you really want to go there?
As an occasional Python programmer who really prefers Python 2.6+, I'd suggest that the experience there is that breaking changes are reasonably straightforward to deliver as long as they're small enough and have a sane deprecation window. 2.6 introduced the `with` and `as` keywords, which broke some code dating from the 2.4 and below era, and changed strings to not be throwable, with the same effect. Thanks to a warning in Python 2.5 and a good period of time to effect change, the migration was made smoothly enough that barely anyone noticed. The only change in 2.6 I remember causing actual harm to users was object.__init__ (the constructor of the root class) being changed to take no parameters. If there had been a deprecation process with runtime warnings for that too, it might not have broken that one IRC bot. Python 2.6 is widely used and adoption didn't suffer, despite unusually many seriously backwards-incompatible changes. It wasn't all sunshine and rainbows for everybody, but it wasn't impossible or even actually particularly difficult for anyone. Backwards incompatible changes can be made in an organized way that gives time for proper preparations and ensures a smooth transition. I don't think Python 3 is the only and most useful example of backwards compatibility breakage. -- Devin _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
