The beginning of the PEP (linked document) has a rationale for it, including an argument that matrix multiplication has a combination of features which distinguish it from other binary operations. Check it out. Like most Python PEPs it is quite readable. There are even alternative proposals and links to where the discussion of this issue has occurred.

It seems that the most fundamental reason is that matrix and memberwise multiplication are two distinct operations which use the same datatypes as operands and both have a very good claim to use of the * operator.

Also, just because a language is general purpose does not mean that it cannot support features which might be restricted in their use.

Two of the python's most popular uses are in scientific and numeric fields (see SciPy, NumPy and ipython). This operator seems like it would be very useful for improving readability in those areas which is probably reason enough to use it.

However, please resist the urge to just overload this new operator for something unrelated that you want. The point of infix operators is to improve the readability of code and lessen the cognitive load on the reader. Overloading an operator for a purpose which is not conventional goes exactly against this for... what benefit exactly?

Thanks. I understand its importance to scientific computing and I welcome the change. I was just wondering if matrix multiplication had more flexible uses, like `sum` does.

And the benefit of overloading is still readability, when carefully used and in a different ___domain. And sparingly. For the `@` operator I will be trying it as an "at" operator for accessing objects from a game map, or some sort of translation. If it performs well I may start using it in my pet projects. If it changes my life and enlightens everyone who gazes upon it, I may start using in production.

I do understand your worry and I promise to be extra careful.

> For the `@` operator I will be trying it as an "at" operator for accessing objects from a game map

I suppose you could use it for that that, but wouldn't that be a canonical case for indexing with []?

A little late, but I think the reply is worth it.

`[]` is for discrete elements. That's perfect for a tile game.

My idea with `@` is a sort of collision detection for continuous maps. `map @ (115.2, 23.5)` should return the object under that position.

This operation is useful on all sorts of interactions: "can I move there?", "what did the mouse click?", "do I have a line of sight?", etc.

I'm still thinking on how to chain those operations.

I, for one, welcome our new operator overloads. Partly a recognition of just how massive Python has become within the scientific community.

Here's my uneducated guess: the Python maintainers see NumPy as a bit of a killer app, and the NumPy maintainers would like to be a MATLAB killer. The entire MATLAB language is designed to make life easier when dealing with matrices (people think it stands for MATh LAB but it actually stands for MATrix LAB.)

MATLAB went down the matrix rabbit hole so far, they made ordinary scalars second-class types. If you want to multiply scalars or otherwise do element-wise operations, you have to prefix the '*' operator with a '.'. If Python can make their language more linear-algebra friendly while avoiding that sort of silliness, I'm all for it.

You don't have to use .* and friends when operating in 2 scalers, 2 * 3 works just fine. But if you have 2 matrices A and B, A * B does a matrix multiplication, And A .* B is needed for element wise multiplication.

I'm still new to matlab, but the place where this has bitten me is if I'm trying to write code that works on either a scalar or vector of scAlars, if you aren't specific, the code my run fine against a single scalar, but blow up or do the wrong thing with a vector.

Ehm, Python is not a "scripting language". It is a — as you said — general purpose programming language. And it is becoming more and more popular for scientific applications, where matrix multiplication plays a key role.

I honestly didn't expect a downvote for calling Python a "scripting language". I use the term loosely and always thought Python fit spot on. I still think it applies here, but I've edited the parent post to correct this possibly incorrect usage of the word.

Just for the record, these are the characteristics of Python that made me call it "scripting":

- Interpreted

- Highly expressive

- No boilerplate

- Vast majority of programs are short

- Lots of libraries for gluing stuff together

- Used for turing-complete customization of software in other languages (e.g.: Sublime Text)

- Recommended as replacement for Bash in some cases

Anyway, I'm happy to see the language evolving to meet its users' needs.

Stolen from https://www.python.org/doc/humor/ (in response to a claim that it's not a true OO language):

> Indeed, and because it doesn't support closures, it's not a true functional programming language either. And because you have to import all sorts of modules to do the simplest things (e.g., regular expressions), neither is it a true scripting language. Indeed, because it doesn't support labeled break or continue statements, it's not even a true structured programming language.

I think the point is, trying to classify programming languages (except ___domain specific ones like SQL or maybe PHP) is kind of pointless.

But to answer your real question, Python is one of the top languages in number crunching. After web work, that's Python's second biggest niche.

> it doesn't support closures

It does now, and thank goodness, because even C++ has closures these days.

I believe that the common usage of python has switched away from "scripting usage" - it's now generally used to implement stuff, not glue stuff together or replace bash, and the vast majority of programs isn't short anymore.

It can be used as a scripting language, but that doesn't seem to be the main use-case anymore.

No offense intended. I just have a slightly different understanding of a "scripting language": a — often ___domain-specific — language that is merely used to write small scripts/macros. But anyway, I did not want to start a discussion about that. Sorry for that.

The standard implementation of Python is compiled to bytecode, like most modern mainstream languages, not interpreted.

I'm sorry, but how is Python not a scripting language?

It is just that "scripting" is now called "managed" because it hurts ego to be a scripting programmer.

It's addressed in the PEP, even with some convincing empirical data. Python is becoming hugely popular as a scientific data processing language. This paragraph from the motivation summarizes:

"We all live in our own little sub-communities, so some Python users may be surprised to realize the sheer extent to which Python is used for number crunching -- especially since much of this particular sub-community's activity occurs outside of traditional Python/FOSS channels. So, to give some rough idea of just how many numerical Python programmers are actually out there, here are two numbers: In 2013, there were 7 international conferences organized specifically on numerical Python [3] [4]. At PyCon 2014, ~20% of the tutorials appear to involve the use of matrices [6]."