On 9/18/2017 5:21 PM, John Ladasky wrote:
On Saturday, September 16, 2017 at 11:01:03 PM UTC-7, Terry Reedy wrote:
On 9/16/2017 7:04 PM, b...@g...com wrote:
<snip>
The particular crippler for CLBG problems is the non-use of numpy in
numerical calculations, such as the n-body problem. Numerical python
extensions are over two decades old and give Python code access to
optimized, compiled BLAS, LinPack, FFTPack, and so on. The current one,
numpy, is the third of the series. It is both a historical accident and
a continuing administrative convenience that numpy is not part of the
Python stdlib.
OK, I found this statement intriguing. Honestly, I can't function without
Numpy, but I have always assumed that many Python programmers do so.
True. Very few websites need numpy. Ditto for some other categories.
> Meanwhile: most of the time, I have no use for urllib, but that
module is in the standard library.
Urllib is comparable in scope to, say, BLAS, or even to the math +
statistics module. And it is less dependent on particular systems.
Django and associated modules, which is comparable, in its own way, to
numpy + scipy, is also not in the stdlib, and should not be.
I noticed the adoption of the @ operation for matrix multiplication. I have
yet to use it myself.
So is there a fraction of the Python community that thinks that Numpy should in
fact become part of the Python stdlib?
Only naive beginners, I should think.
What is the "administrative convenience" to which you refer?
Numerical analysis is quite different from compiler construction and
communication protocols. So numpy needs its own set of developers,
policies, decision process, release schedule, etc. It took an expert in
the field to persuade the numerical and numarray people to join together
to produce numpy. PSF provides the infrastructure that makes 'pip
install numpy' or 'pip install django' possible. Separate groups
provide the content.
Does this make sense?
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
