Re: [Python-ideas] Is it Python 3 yet?
Resending because Google Groups handling of mailing lists is broken :-( Sorry to anyone who gets double posts. On 27 January 2017 at 08:39, Paul Moore <p.f.moore@gmail.com> wrote:
On 27 January 2017 at 06:22, Denis Akhiyarov <denis.akhiyarov@gmail.com> wrote:
The problem is not in Python packages, but when gluing Python with other Windows apps or libraries.
I would argue that anyone doing that is capable of looking for the version they need. The proposal is simply to make the 64-bit version what we offer by default, not to remove the 32-bit versions or even to make them less prominent anywhere other than on the front page.
Paul
Hi all, FWIW, I got the following statement from here: https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows "Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS libraries and are 32-bit only because of the difficulty of compiling ATLAS on 64-bit Windows. " Might want to double-check with the numpy folks; it would be too bad if numpy wouldn't work on the preferred Windows Python. Stephan 2017-01-27 9:45 GMT+01:00 Paul Moore <p.f.moore@gmail.com>:
Resending because Google Groups handling of mailing lists is broken :-( Sorry to anyone who gets double posts.
On 27 January 2017 at 08:39, Paul Moore <p.f.moore@gmail.com> wrote:
On 27 January 2017 at 06:22, Denis Akhiyarov <denis.akhiyarov@gmail.com> wrote:
The problem is not in Python packages, but when gluing Python with other Windows apps or libraries.
I would argue that anyone doing that is capable of looking for the version they need. The proposal is simply to make the 64-bit version what we offer by default, not to remove the 32-bit versions or even to make them less prominent anywhere other than on the front page.
Paul
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Jan 27, 2017 at 1:32 AM, Stephan Houben <stephanh42@gmail.com> wrote:
Hi all,
FWIW, I got the following statement from here:
https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows
"Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS libraries and are 32-bit only because of the difficulty of compiling ATLAS on 64-bit Windows. "
Might want to double-check with the numpy folks; it would be too bad if numpy wouldn't work on the preferred Windows Python.
That's out of date -- official numpy releases have switched from ATLAS to OpenBLAS (which requires some horrible frankencompiler system, but it seems to work for now...), and there are 32- and 64-bit Windows wheels up on PyPI: https://pypi.python.org/pypi/numpy/ 64-bit is definitely what I'd recommend as a default to someone wanting to use numpy, because when working with arrays it's too easy to hit the 32-bit address space limit. -n -- Nathaniel J. Smith -- https://vorpus.org
On 1/27/2017 4:38 AM, Nathaniel Smith wrote:
On Fri, Jan 27, 2017 at 1:32 AM, Stephan Houben <stephanh42-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi all,
FWIW, I got the following statement from here:
https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows
"Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS libraries and are 32-bit only because of the difficulty of compiling ATLAS on 64-bit Windows. "
Might want to double-check with the numpy folks; it would be too bad if numpy wouldn't work on the preferred Windows Python.
That's out of date
Would be nice if it were updated... -- official numpy releases have switched from ATLAS
to OpenBLAS (which requires some horrible frankencompiler system, but it seems to work for now...), and there are 32- and 64-bit Windows wheels up on PyPI: https://pypi.python.org/pypi/numpy/
and from NumPy, a fundamental package needed for scientific computing with Python. Numpy+MKL is linked to the Intel® Math Kernel Library and includes required DLLs in the numpy.core directory. numpy‑1.11.3+mkl‑cp27‑cp27m‑win32.whl numpy‑1.11.3+mkl‑cp27‑cp27m‑win_amd64.whl etc. All the several packages that require numpy also come in both versions.
64-bit is definitely what I'd recommend as a default to someone wanting to use numpy, because when working with arrays it's too easy to hit the 32-bit address space limit.
-n
-- Terry Jan Reedy
So I realize this is subjective and just a personal experience, but over the last 3-5 years I've really watched Python usage and popularity decline in the "hearts and minds" of my peers, across a few different companies I work with. At my current gig we don't even use Python anymore for tools that will be distributed to an end user; we only use Python for internal tooling. With a still difficult distribution/compatibility story, I've watched dozens of instances where people choose something else, usually Node or Golang. The primary uses here are api and microservice-type applications, developer tooling, and CLI apps. Even recent additions like `async` keyword are causing more problems because it's not a useful general-purpose concurrency primitive eg. like a goroutine or greenlets. I know the scientific community is a big and important part of the Python ecosystem, but I honestly believe other parts of Python are suffering from any dragging of feet at this point. Python 3 has been out nearly a decade, and I think it would be super for the community to take a bold stance (is it still bold 9 years later?) and really stand behind Python 3, prominently, almost actively working to diminish Python 2. I've been hearing and reading about both for a long time, and honestly I'd love one of them to go away! I don't even care which :-) On Fri, Jan 27, 2017 at 4:25 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 1/27/2017 4:38 AM, Nathaniel Smith wrote:
On Fri, Jan 27, 2017 at 1:32 AM, Stephan Houben < stephanh42-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi all,
FWIW, I got the following statement from here:
https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows
"Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS libraries and are 32-bit only because of the difficulty of compiling ATLAS on 64-bit Windows. "
Might want to double-check with the numpy folks; it would be too bad if numpy wouldn't work on the preferred Windows Python.
That's out of date
Would be nice if it were updated...
-- official numpy releases have switched from ATLAS
to OpenBLAS (which requires some horrible frankencompiler system, but it seems to work for now...), and there are 32- and 64-bit Windows wheels up on PyPI: https://pypi.python.org/pypi/numpy/
and from
NumPy, a fundamental package needed for scientific computing with Python. Numpy+MKL is linked to the Intel® Math Kernel Library and includes required DLLs in the numpy.core directory.
numpy‑1.11.3+mkl‑cp27‑cp27m‑win32.whl numpy‑1.11.3+mkl‑cp27‑cp27m‑win_amd64.whl etc.
All the several packages that require numpy also come in both versions.
64-bit is definitely what I'd recommend as a default to someone
wanting to use numpy, because when working with arrays it's too easy to hit the 32-bit address space limit.
-n
-- Terry Jan Reedy
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- C Anthony
On Fri, Jan 27, 2017, at 12:54, C Anthony Risinger wrote:
I know the scientific community is a big and important part of the Python ecosystem, but I honestly believe other parts of Python are suffering from any dragging of feet at this point. Python 3 has been out nearly a decade, and I think it would be super for the community to take a bold stance (is it still bold 9 years later?) and really stand behind Python 3, prominently, almost actively working to diminish Python 2.
This particular subthread is regarding whether to make a 64-bit version of python 2 and/or 3 (whatever is done regarding the other question) the default download button for users coming from Win64 browsers. At least, the bits you're responding to are talking about 32-bit libraries rather than Python 2.
On Jan 27, 2017 4:51 PM, "Random832" <random832@fastmail.com> wrote: On Fri, Jan 27, 2017, at 12:54, C Anthony Risinger wrote:
I know the scientific community is a big and important part of the Python ecosystem, but I honestly believe other parts of Python are suffering from any dragging of feet at this point. Python 3 has been out nearly a decade, and I think it would be super for the community to take a bold stance (is it still bold 9 years later?) and really stand behind Python 3, prominently, almost actively working to diminish Python 2.
This particular subthread is regarding whether to make a 64-bit version of python 2 and/or 3 (whatever is done regarding the other question) the default download button for users coming from Win64 browsers. At least, the bits you're responding to are talking about 32-bit libraries rather than Python 2. Yeah, I guess I was trying to push against any further stagnation, of any kind, on forward-facing questions like 32/64 bit and 2/3 version. I hesitated to say anything because I don't feel I'm adding much concrete or even useful information to the conversation, but it's something that's been building internally for a long time while observing the overarching tone and outcomes of Python threads. I can't articulate it we'll, or even fully isolate the reasons for it. All I really know is how I feel when peers ask me about Python or the reading I get when others speak about their experience using it. Python is absolutely one of my favorite languages to write, yet I find myself recommending against it, and watching others do the same. Python comes with caveats and detailed explanations out the gate and people simply perceive higher barriers and more chores. I don't have any truly constructive input so I'll stop here; I only wanted to voice that in my tiny tiny bubble, I'm watching market share diminish, it's unfortunate, and I'm not sure what to do about it.
participants (6)
-
C Anthony Risinger -
Nathaniel Smith -
Paul Moore -
Random832 -
Stephan Houben -
Terry Reedy