3 ms·

I think numpy is mostly great. Although I do agree - numpy should be in the stdlib, period. So many users come from the scientific/data/simulation communities.

I think numpy is mostly great. Although I do agree - numpy should be in the stdlib, period. So many users come from the scientific/data/simulation communities. It’s just that there are no (or too few) core devs from that tradition. Python lacking numpy in the base language is as awful as Fortran lacking dict-like data structures in its runtime.

enriquto 6y ago
> numpy should be in the stdlib, period. I disagree strongly with this. Numerical facilities should not be in the stdlib, they should be in the language itself, without need to "import" anything. I can create strings and dictionaries without any imports. I should be able to create a multidimensional array of floats, and perform natural operations with it (like matrix multiplication) without importing anything. As per the dictionaries in Fortran, there are libraries for that. But I think that not having complex data structures in Fortran is a feature, not a bug. If you actually need these data structures, many Fortran programmers will tell you to just use a different language. You'll never hear such a plainly honest answer from Python programmers; they'll tell you instead to use bizarre libraries with unnatural interfaces, and you'll be forced to multiply matrices using a function "numpy.dot" or an ugly operator "@".
- fishmaster 6y ago
  This is exactly why I'm going to Julia. It either has these constructs in the language itself or is powerful enough to express them adequately. Numpy is a necessary crutch for Python.
  - pc86 6y ago
    You're going to Julia so that you can avoid typing "import numpy as np" at the beginning of a file? Or is there more to it?
    - fishmaster 6y ago
      Also so that I don't have to use things like "np.dot(A, B)" and similar annoyances.
    - axi1 6y ago
      As a sidenote, I don't write "import numpy as np" in jupyter notebooks (at least as long as I don't share them with others) for I have this line in my ipython startup file.
    - dklend122 6y ago
      Mathematical programming in Julia is just more natural and integrated with the language and type system. From dot broadcasting, to multiple dispatch, to parametric types (if you want ), multidimensional array comprehensions. No worrying about 4 different container types (list, np array, pytorch tensor, symbolic etc etc) Everything works with one array abstraction, including gpu and multi threaded
      - fishmaster 6y ago
        This is what I mean with it being more natural and elegant in Julia. Also, "@code_warntype" is incredibly useful for efficient code.
- rbanffy 6y ago
  > I disagree strongly with this. Numerical facilities should not be in the stdlib, they should be in the language itself, Overloading the language with features that have limited use for most of their users would tie their release cycles and end up a disservice to both users of the language in general and those who use it for heavy number crunching. As for @, my guess is that Python is running out of ASCII symbols for operators (and unwilling to go full APL with operators). I would imagine that, if NumPy arrays don't support @ (don't they?!), it'd be a desire to be compatible with pre 3.5, which is when the @ infix operator was introduced. It shouldn't be much trouble to implement __matmul__ and __rmatmul__ for them, assuming NumPy's own interfaces are sane.
  - zhd 6y ago
    Numpy arrays do indeed support the @-operator for matrix multiplication. In fact, one of the common design questions when adding the @-operator to Python was "why do this, when it's not used anywhere in the core language or standard library?" - and the answer was "because it's important for Numpy and the numerical user community". (and finally, adding __matmul__ and __rmatmul__ is entirely backwards compatible; you can use objects with those methods on Python 3.4 - it's only `A @ B` which is a syntax error)
- pletnes 6y ago
  Very good argument for having that in the python language, that is true. It’s an even bigger ask, though. In Fortran you often need such data structures to keep track of results or to do IO. It’s a pain and I’ve so far not seen a usable library for it.

enriquto 6y ago

> numpy should be in the stdlib, period. I disagree strongly with this. Numerical facilities should not be in the stdlib, they should be in the language itself, without need to "import" anything. I can create strings and dictionaries without any imports. I should be able to create a multidimensional array of floats, and perform natural operations with it (like matrix multiplication) without importing anything. As per the dictionaries in Fortran, there are libraries for that. But I think that not having complex data structures in Fortran is a feature, not a bug. If you actually need these data structures, many Fortran programmers will tell you to just use a different language. You'll never hear such a plainly honest answer from Python programmers; they'll tell you instead to use bizarre libraries with unnatural interfaces, and you'll be forced to multiply matrices using a function "numpy.dot" or an ugly operator "@".

fishmaster 6y ago
This is exactly why I'm going to Julia. It either has these constructs in the language itself or is powerful enough to express them adequately. Numpy is a necessary crutch for Python.
- pc86 6y ago
  You're going to Julia so that you can avoid typing "import numpy as np" at the beginning of a file? Or is there more to it?
  - fishmaster 6y ago
    Also so that I don't have to use things like "np.dot(A, B)" and similar annoyances.
  - axi1 6y ago
    As a sidenote, I don't write "import numpy as np" in jupyter notebooks (at least as long as I don't share them with others) for I have this line in my ipython startup file.
  - dklend122 6y ago
    Mathematical programming in Julia is just more natural and integrated with the language and type system. From dot broadcasting, to multiple dispatch, to parametric types (if you want ), multidimensional array comprehensions. No worrying about 4 different container types (list, np array, pytorch tensor, symbolic etc etc) Everything works with one array abstraction, including gpu and multi threaded
    - fishmaster 6y ago
      This is what I mean with it being more natural and elegant in Julia. Also, "@code_warntype" is incredibly useful for efficient code.
rbanffy 6y ago
> I disagree strongly with this. Numerical facilities should not be in the stdlib, they should be in the language itself, Overloading the language with features that have limited use for most of their users would tie their release cycles and end up a disservice to both users of the language in general and those who use it for heavy number crunching. As for @, my guess is that Python is running out of ASCII symbols for operators (and unwilling to go full APL with operators). I would imagine that, if NumPy arrays don't support @ (don't they?!), it'd be a desire to be compatible with pre 3.5, which is when the @ infix operator was introduced. It shouldn't be much trouble to implement __matmul__ and __rmatmul__ for them, assuming NumPy's own interfaces are sane.
- zhd 6y ago
  Numpy arrays do indeed support the @-operator for matrix multiplication. In fact, one of the common design questions when adding the @-operator to Python was "why do this, when it's not used anywhere in the core language or standard library?" - and the answer was "because it's important for Numpy and the numerical user community". (and finally, adding __matmul__ and __rmatmul__ is entirely backwards compatible; you can use objects with those methods on Python 3.4 - it's only `A @ B` which is a syntax error)
pletnes 6y ago
Very good argument for having that in the python language, that is true. It’s an even bigger ask, though. In Fortran you often need such data structures to keep track of results or to do IO. It’s a pain and I’ve so far not seen a usable library for it.