Marc-Andre Lemburg added the comment: On 11.05.2015 21:03, Steve Dower wrote: > > Steve Dower added the comment: > > Simply because I didn't update the doc string :) > > I don't really want to put a version number on this file, since it isn't MSVC > 14.0 specific - it's MSVC 14 and all future versions. We don't check the > build version anymore, though get_build_version() is still there (hardcoded > to 14.0) > > As you say, the existing modules are legacy, so I wonder what would be useful > from them? They refer to compilers that aren't available and won't be useful > for Python 3.5 to the extent that I'd really like to discourage using them. > The modules themselves are undocumented and were not available on other > platforms, so any code using them should be protecting themselves against > ImportError already, and they're going to be broken anyway so they may as > well break early. > > But my main question is why would you still need the old versions around, > given that compatibility is already broken?
In Python 2, distutils could be easily be used on earlier Python versions, simplifying the amount of work you'd need to do in your setup.py to address differences between the various Python versions you wanted to support. I don't know what the deal is for Python 3. Apart from that, it may be necessary to compile some parts of C extensions with older compilers. Probably a rare case, but then again: what do we gain by removing the old code ? Note that VC9 was handled in the same way: it was added to the set rather than replacing it. That was done in the Python 2 series, though, where the above guarantee was used as basis, so things may be different for Python 3. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23970> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
