[issue37980] regression when passing numpy bools to sorted(..., reverse=r)
Change by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <https://bugs.python.org/issue37980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)
Change by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <https://bugs.python.org/issue38501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40897] Inheriting from Generic causes inspect.signature to always return (*args, **kwargs) for constructor (and all subclasses)
Change by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <https://bugs.python.org/issue40897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
Change by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Changes by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Changes by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <http://bugs.python.org/issue16296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Ralf Gommers added the comment:
I'll note that in Numpy we have now worked around the issue (with
https://github.com/numpy/numpy/pull/4892), basically by monkeypatching
distutils and doing:
if '/MANIFEST' not in ldflags:
ldflags.append('/MANIFEST')
The bug report is still valid though; it should not be specific to numpy. A
more detailed report of what was broken before and fixed by this patch would
have been helpful. I cannot be sure that this is 100% correct because I don't
have Windows+MSVC available, but it should be this:
- Take Python 3.4 installed from the python.org .exe installer
- Create a new virtualenv and activate it
- pip install numpy==1.8.0 # this will fail
- apply the patch
- pip install numpy==1.8.0 # this will work
Furthermore I think that this is a duplicate of
http://bugs.python.org/issue4431, which is also a valid bug report confirmed by
multiple people (but closed as "not a bug").
Given that applying the patch is harmless and not applying it clearly does
create problems for users, it would make sense to apply it. But honestly, given
for how long the bug reports on 4431 were ignored, I'm not willing to spend
much effort on this. So if no one else does either, this issue may indeed just
as well be closed as outdated like Marc Lawrence suggests.
--
___
Python tracker
<http://bugs.python.org/issue16296>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ralf Gommers added the comment: > @Steve Great, so what needs to be done so that I as a package developer can > do `pip install windows-build-system`, `python setup.py bdist_wheel` and it > actually creates a wheel? (which AFAICT is the same problem). Hi Henry, I expect progress on the mingw-w64 front within the next few months. There'll be a status update with some more concrete plans soon. Also, http://mingwpy.github.io/ has appeared last week - a few wheels have been set in motion. > The advice has always been "Visual Studio X" is what is needed, and for 3.5 > onwards that becomes "Visual Studio 2015 or later". Hi Steve, that's actually not very useful advice for the scientific Python community. While things like C99 compliance are or could get better, there will always be a large Fortran-shaped hole in your suggestion. See my post above (from May 19) for more details. -- ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ralf Gommers added the comment: > "We" is a lot of different companies and individuals. Anyone distributing > prebuilt binaries is helping here, a few people are working on the licensing > concerns for some components, other people are working on C BLAS libraries. Note that we by default recommend to users to use a distribution like Anaconda/Canopy (for example at http://scipy.org/install.html). That's fine for many scientific users, but not for people that already have a Python stack installed or simply prefer to use pip for another reason. So pre-built binaries like the ones in Anaconda/Canopy help, but don't solve the "make `pip install scipy` work" problem. And giving up on pip/PyPi would make no one happy... > I see the issue approximately as "it's hard to install the scipy stack", > which is broader than "Windows does not have a Free Fortran compiler" It's: "it's hard to install the scipy stack on Windows". On OS X and Linux it's really not that hard. On OS X, you can install all core packages with pip (there are binary wheels on PyPi). On Linux you can do that too after using your package manager to install a few things like BLAS/LAPACK and Python development headers. And the lack of Windows wheels on PyPi is directly related to no free Fortran compiler. > and allows for more solutions (apologies for putting words in your mouth, > which is not my intent, though I have certainly seen a fixation on this one > particular solution to the exclusion of other possibilities). Much more effort has gone into pre-built binaries than into MinGW, as well as into other things that help but can't be a full solution like a C BLAS. And I haven't seen other solutions to "make the scipy stack pip-installable" that could work. So I have to disagree with "fixation". -- ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ralf Gommers added the comment: > I'm happy and keen to help so please feel free to poke me if you need > assistance with anything. I'll keep an eye out too - is it actively being > discussed on any list? Thanks Henry. There's no ongoing discussion on a list right now, but give it a week or two. I'll make sure to ping you. -- ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ralf Gommers added the comment: Hi all, There is now a much more concrete plan for the static MinGW-w64 based toolchain, and the first funding has materialized. Please see the announcement on the Numpy mailing list (http://article.gmane.org/gmane.comp.python.numeric.general/62207), the MingwPy site (http://mingwpy.github.io/) and in particular the "main milestones" in http://mingwpy.github.io/proposal_december2015.html -- ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution
Changes by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <http://bugs.python.org/issue23102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23114] "dist must be a Distribution instance" check fails with setuptools
Changes by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <http://bugs.python.org/issue23114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution
Ralf Gommers added the comment: Any chance to get this merged? -- versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue23102> ___ ___ 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
Changes by Ralf Gommers : -- nosy: +ralf.gommers ___ Python tracker <http://bugs.python.org/issue2943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ralf Gommers added the comment: A few comments from the perspective of what's needed for the scientific Python stack: 1. Of the three options mentioned in msg243605, it's definitely (3) that is of interest. We want to build extensions with MinGW-w64 that work with the standard MSVC Python builds. We've done this with mingw32 for a very long time (which works fine); not being able to do this for 64-bit extensions is the main reason why there are no official 64-bit Windows installers for Numpy, Scipy, etc. 2. There is work ongoing on a mingw-w64 toolchain that would work for the scientific Python stack: https://github.com/numpy/numpy/wiki/Mingw-static-toolchain. It actually works pretty well today, what needs to be sorted out is ensuring long-term maintainability. More details about what it's based on are provided in https://github.com/numpy/numpy/wiki/Mingw-w64-faq - I think it's consistent with what Ruben van Boxem recommends. Carl Kleffner, who has done a lot of the heavy lifting on this toolchain, is working with upstream mingw-w64 and with WinPython to ensure not creating yet another incompatible flavor mingw. 3. It's good to realize why making mingw-w64 work is especially important for the scientific Python stack: there's a lot of Fortran code in packages like Scipy, for which there is no free compiler that works with MSVC. So one could use MSVC + ifort + Intel MKL (which is what Enthought Canopy and Continuum Anaconda do), but that's quite expensive and therefore not a good solution for the many of contributors to the core scientific Python stack nor okay from the point of view of needing to provide official binaries that can be redistributed. Paul's comments on picking a single mingw-w64 version, and that version not being a download from someone's personal homepage, make a lot of sense to me. We (Carl & several core numpy/scipy/scikit-learn devs) happened to have planned a call on this topic soon in order to move towards a long-term sustainable plan. I wouldn't expect everything to be sorted out in a couple of weeks (it's indeed a hard goal), but knowing that Paul is willing to review and merge patches definitely helps. -- ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ralf Gommers added the comment: Indeed, our idea of "easy to install" was/is a wheel or set of wheels so that "pip install mingw64py" does all you need. If necessary that can of course be repackaged as single download to unzip as well. -- ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
