Hacker News Reader

Comment by enriquto | Hacker News Reader

> 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 "@".

View on HN

> 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.

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)

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.

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.

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?

Also so that I don't have to use things like "np.dot(A, B)" and similar annoyances.

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.

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

This is what I mean with it being more natural and elegant in Julia. Also, "@code_warntype" is incredibly useful for efficient code.

Reply on news.ycombinator.com