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.