<div><span style="color: rgb(160, 160, 168); ">On Tuesday, March 5, 2013 at 7:50 AM, Mark McLoughlin wrote:</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><blockquote type="cite"><div><div>I still don't really see how this is related to PEP426 unless PEP426</div><div>has gotten</div><div>a lot larger since I last looked at it. Where in particular a</div><div>distribution gets</div><div>installed is left up to the installers to sort out. And making sure</div><div>that the installed</div><div>versions exist in sys.path is similarly out of scope for PEP426.</div></div></blockquote><div><br></div><div>Sorry, maybe I'm being obtuse.</div><div><br></div><div>I can see people read PEP426 and thinking "oh, awesome! Python now has a</div><div>mechanism for handling incompatible API changes! Now I can get rid of</div><div>that crufty backwards compat code and bump my major number!".</div><div><br></div><div>My point is that it's (potentially) damaging to send that message to</div><div>library maintainers before Python has the infrastructure for sanely</div><div>dealing with parallel installs.</div></span></blockquote><div>Gotcha, you think that codifying how to version with regards to breaking</div><div>API compatibility will lead to more people breaking backwards compatibility.</div><div><br></div><div>That's a fair concern, and there's not much that can be done inside of PEP426</div><div>to alleviate it. However I will say that PEP426 doesn't really contain much</div><div>in the way of new ideas, but rather codifies a lot of existing practices within the</div><div>Python community so that tools can get simpler and more accurate without</div><div>having to resort to heuristics and guessing.</div><div><br></div><div>You could also argue that this would _help_ with backwards compatibility because</div><div>there is now a suggested way of declaring when 2 releases are no longer compatible</div><div>by incrementing the major version number.</div>