> [Guido] > > Depends on how you fix these. Fixing the code may break more code > > than fixing the docs (assuming the mismatch existed for a long time)! [Steve] > Such as the socket mismatch that was fixed in (IIRC) 1.6, to loud > complaints from half the network programming world? This still bites > occasionally when old cord has to be brought forward to more recent > versions (though, of course, it isn't hard to make the necessary > changes). That was not a micro release. I'm glad we fixed that one then; now it would be a much bigger disaster. (And it was not a matter of adjusting to the docs, but adjusting to the fact that not all socets deal with host/port pairs.) > [...] > Yup. Any potential for code breakage is going to cause somebody > somewhere a certain amount of pain. It's these edge cases that cause > most of the problems, since overall the version-to-version compatibility > picture is actually remarkably good. But people will cheerfully ignore > the 99.99% of their code that *doesn't* break, and bitch about the > little bits that do :-) For people with a large code base and real customers, the only working approach is long, careful testing with each new Python release. Hence the call for Python-in-a-tie. (Though I haven't heard much about that recently -- I've even heard a call to upgrade the tie to 2.3.) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4