[issue25251] Unknown MS Compiler version 1900
Matt Hickford added the comment: Hi Ateik. Find cygwinccompiler.py on your computer and copy the patch to the same folder. Then run the command `patch < patch.diff`. It that doesn't work, just open both files in a text editor and copy and paste the lines to the right place, you'll work it out. It may or not solve your problem. On 15 November 2015 at 12:30, Ateik Al-Zehla <rep...@bugs.python.org> wrote: > > Ateik Al-Zehla added the comment: > > how to apply patch file : patch.diff ? plz help > > -- > nosy: +Ateik Al-Zehla > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue25251> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25251] Unknown MS Compiler version 1900
Matt Hickford added the comment: I'm not sure what the correct analogue of msvcr100 is for Visual C++ 14.0. "msvcr140.dll no longer exists" http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx elif msc_ver == '1600': # VS2010 / MSVC 10.0 return ['msvcr100'] elif msc_ver == '1900': -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25250] AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'
Matt Hickford added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue25250> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25250] AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'
Matt Hickford added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue25250> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25250] AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'
Matt Hickford added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue25250> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25250] AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'
New submission from Matt Hickford: 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 -- components: Distutils messages: 251724 nosy: Matt.Hickford, dstufft, eric.araujo priority: normal severity: normal status: open title: AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version' type: crash versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25251] Unknown MS Compiler version 1900
New submission from Matt Hickford:
Hi distutils. I previously used compiler=mingw32 with success. Today I
installed Visual Studio 2015. Now compiler=mingw32 gives me an error
File "c:\python35\lib\distutils\cygwinccompiler.py", line 86, in get_msvcr
raise ValueError("Unknown MS Compiler version %s " % msc_ver)
ValueError: Unknown MS Compiler version 1900
Any ideas? I don't understand why what msvc I have installed affects build with
mingw32
--
components: Distutils
messages: 251730
nosy: Matt.Hickford, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Unknown MS Compiler version 1900
type: crash
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25251>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2943] Distutils should generate a better error message when the SDK is not installed
Matt Hickford added the comment: For comparison, Ruby ships with a package manager, Gem. If a user tries to install a package with C extensions, they are given this user-friendly message: Please update your PATH to include build tools or download the DevKit from 'http://rubyinstaller.org/downloads' and follow the instructions at 'http://github.com/oneclick/rubyinstaller/wiki/Development-Kit' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2943 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2943] Distutils should generate a better error message when the SDK is not installed
Matt Hickford added the comment: ( Upstreamed from Pip https://github.com/pypa/pip/issues/942 ) There are lot of Python users on Windows. If they succeed in installing a package manager (a struggle), this is typically their first experience with it $ pip install numpy blah blah blah Error: Unable to find vcvarsall.bat The misery is compounded by the cryptic error message. They don't know whether the problem with their computer, the specific package, or pip generally. Let alone how to fix it. You and I know this happens because the package install involves building some C code from source and the user doesn't have a C compiler installed. The fix is to install mingw32 (or Visual Studio) and edit distutils.cfg to specify to use that compiler. Thus, it would be really helpful to print a message after 'error: unable to find vcvarsall.bat' such as Installing this package requires a C compiler. To fix this error, follow http://stackoverflow.com/q/2817869/284795 -- nosy: +Matt.Hickford ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16675] Ship Python with a package manager
Matt Hickford added the comment: Please could you share a link to a previous discussion about packaging? I'm interested in user experience 'Python should ship with first class package management like other languages' rather than technical details 'Python should ship with distutils rather than setuptools. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16675] Ship Python with a package manager
New submission from Matt Hickford: Python should ship with a full-featured package manager. Why? 1. Most programmers would rather use a reliable maintained library for a common task than roll their own code. Then the programmer can get on with solving their unique problems. This assumes the library is convenient to install (and licensed appropriately). 2. Other languages ship with package managers - Ruby with Gem, Nodejs with Npm. As a result, these languages have extremely successful open-source communities encouraging sharing. https://github.com/languages Yes, Python has a strong open-source community, but there's a real hurdle to publishing packages. Nodejs is still in short trousers, but https://npmjs.org/ will shortly outnumber Python's package index. If you believe sharing is worthwhile, then you should want to make it easy. Python has a decent package manager (distribute + pip) but it's ironically complicated to install. On Windows 64 bit (a very popular platform), this requires installing a package from source. You, dear Reader, surely find that easy, but it's still a big an ask for anyone new to programming. You perhaps recommend Python to friends wishing to learn programming. Could you explain over the phone how to install a package such as 'requests'? The Django homepage actually forsakes Python package management and encourages new users to build from source. You only have to write 'python install package' into Google or read http://stackoverflow.com/questions/4750806/how-to-install-pip-on-windows to see just how much *pain* new users have with package management. I humbly suggest pip (+ distribute), which happens to be the community's de facto standard. -- messages: 177437 nosy: Matt.Hickford priority: normal severity: normal status: open title: Ship Python with a package manager type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
