This kind of approach works for one-shot "let's just see if it works" type stuff, but anything that I would stand behind needs at least some level of labeled data and curated dataset.

There is nothing more permanent than temporary.

... and ...

We don't have time to do it right, but we do have time to do it twice.

The -> macro.

  (-> {}
      (add-person 'servbot)
      add-age
      add-info
      add-to-db
      notify-status-by-email
      log-user-addition
  )

Additionally, there is the ->> operator which inserts the previous result as the last argument in the next expression and some a library that includes the "magic wand" operator "-<>" ala

  (-<> {}
      (add-person 'servbot)
      (add-age 21 <>)
      (add-info 'servbot <> 21)
      (add-to-db 'my-db-handle 5432 <>)
      notify-status-by-email
      (log-user-addition 'dev 'email <> 'paint-by-numbers)
  )

Edit: Update for formatting.

I'd also like to point out that I write this a Python-phile that has come to the understanding that Python is great until it isn't. When Python becomes to burdensome, the understanding of the problem delivered by my Python sketch helps to narrow the focus of what I need to solve the problem efficiently. By that time, Go has never been the correct tool for me. I'm comfortable writing solutions in C, Rust and Java, perhaps this is my problem.

Whenever I read or write Go I don't understand how it managed to capture the mindshare that is has. Especially in the face of other technologies available, Go seems like a timid step forward in descriptions of computation, when there are bolder choices that deliver valuable additions to my development ecosystem.

I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak. But I feel that when I make the leap from Python to Go, I admittedly don't understand the allure. Static compiltion is really nice! Statically linked binaries for distribution is very nice! The tooling is out of this world! Hands down, Go has one of the best out of the box toolchains I've ever encountered. But when helping me think about computation, Go doesn't.

Go's concurrency primitives don't feel like a great deal of a step forward compared to C. I know, I know, this is crazy talk. I feel like I am missing some great wisdom about Go, I truly do. Concurrency is really hard and Go has clearly helped a lot of people minimize concurrency problems. But whenever I use channels I am reminded Go does not allow me to shut my brain off, and whenever the deadlock bug strikes, I feel that I might as well be writing C.

I don't mean to disrespect Go and the great things it does, the opposite of that! I am hoping Go delivers a bulletproof abstraction for concurrency. Until then I've become too familiar with other tools to justify using Go for more than incredibly niche use cases. I really hope that will change (both my mindset and Go)!

http://legacy.python.org/dev/peps/pep-0465/#id24

Implementing __matmul__, __rmatmul__ and __imatmul__ will allow you to apply this operator to any given class. In that light, you could subclass the numpy matrix class yourself and simply apply these.

As for whether these will be applied to Python lists, my speculation is: I doubt it. Its possibly the most commonly used data structure, and I doubt they would add the overhead of another set of methods on each instance.