Hi distutils. I wrote a setup.py that conditions on compiler type, following the guide at [1]. I needed to add an extra include when the compiler is an msvc version older than 9.0 (infamously missing stdint.h [2])

Anyway the code I wrote to do this was:

if self.compiler.compiler_type == "msvc" and int(self.compiler._MSVCCompiler__version) <= 9:

Which worked fine on all Python versions (tested 2.7 through 3.4) UNTIL the recent release of Python 3.5. On Python 3.5 I get the error:

AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'

Oh no. My fault I suppose for relying on a private variable. Can you suggest a more reliable way to test "compiler is msvc <= 9.0"? The test should be compatible all Python versions 2.7 through 3.5 so it can safely go in a setup.py

Can you help?

[1] http://stackoverflow.com/a/5192738/284795
[2] https://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio

if sys.version_info[:2] >= (3, 3):
    # MSVC version is >= 9.0

Alternatively:

if sys.version_info[:2] >= (3, 5):
    # MSVC version is >= 14.0, or
    # _msvccompiler.MSVCCompiler does not have __version

or

if self.compiler.compiler_type == "msvc" and int(getattr(self.compiler, '_MSVCCompiler__version'), 10) <= 9:
    # MSVC version is >= 9.0

Hi Steve. Thanks for your reply. In the end I went with your something
similar to your third suggestion. It's important I wanted to condition on
what compiler distutils is using *now* to the build the extension on my
computer, rather than what compiler was originally used to build Python
(which needn't match).

On 29 September 2015 at 05:27, Steve Dower <report@bugs.python.org> wrote:

>
> Steve Dower added the comment:
>
> if sys.version_info[:2] >= (3, 3):
>     # MSVC version is >= 9.0
>
> Alternatively:
>
> if sys.version_info[:2] >= (3, 5):
>     # MSVC version is >= 14.0, or
>     # _msvccompiler.MSVCCompiler does not have __version
>
> or
>
> if self.compiler.compiler_type == "msvc" and int(getattr(self.compiler,
> '_MSVCCompiler__version'), 10) <= 9:
>     # MSVC version is >= 9.0
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue25250>
> _______________________________________
>

Well __version is determined by looking at sys.version to see what version was used to build Python, so you aren't really getting the "actual" one, though in practice it doesn't matter.

For Python 3.5 and later you could get different versions from the one that was used to build, but it will always be at least 14.0 and there's deliberately no way for people to depend on that information other than in C source code.

It matters if you're trying to write a library that builds reliably

1. On Linux
2. On Windows compiler=msvc
3. On Windows compiler=mingw32 (many people set this in distutils.cfg [1])

...for all Python versions 2.6 through 3.5 (24 combinations!) Anyway I
think I've got everything working simultaneously now. Thanks for your help.

Yes I saw that blog post—your blog post—about compiler independence [2]
from msvc 14.0 on. That's great news. Let me go study it.

[1] http://stackoverflow.com/q/3297254/284795
[2] http://stevedower.id.au/blog/building-for-python-3-5-part-two/

On 29 September 2015 at 14:05, Steve Dower <report@bugs.python.org> wrote:

>
> Steve Dower added the comment:
>
> Well __version is determined by looking at sys.version to see what version
> was used to build Python, so you aren't really getting the "actual" one,
> though in practice it doesn't matter.
>
> For Python 3.5 and later you could get different versions from the one
> that was used to build, but it will always be at least 14.0 and there's
> deliberately no way for people to depend on that information other than in
> C source code.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue25250>
> _______________________________________
>

Once you've established that MSVC is being used, you can infer the version from the Python version, is what I meant by "it doesn't matter". The version attribute on the compiler instance is never going to differ pre-3.5, and post-3.5 it doesn't even exist.

Generally, I'd say you're safer to detect and check _MSC_VER in your C code if it's relevant, as that will also handle builds that don't go via your setup.py.

Yes you're right. My setup.py if you're curious
https://github.com/hickford/primesieve-python/blob/master/setup.py

Separately, I think compiler=mingw32 is broken in Python 3.5 on computers
with Visual Studio 2015 installed.  http://bugs.python.org/issue25251 if
that interests you

On 29 September 2015 at 16:24, Steve Dower <report@bugs.python.org> wrote:

>
> Steve Dower added the comment:
>
> Once you've established that MSVC is being used, you can infer the version
> from the Python version, is what I meant by "it doesn't matter". The
> version attribute on the compiler instance is never going to differ
> pre-3.5, and post-3.5 it doesn't even exist.
>
> Generally, I'd say you're safer to detect and check _MSC_VER in your C
> code if it's relevant, as that will also handle builds that don't go via
> your setup.py.
>
> ----------
> resolution:  -> not a bug
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue25250>
> _______________________________________
>