My gut tells me the logical `or` here should use the word "or" like in the rest of the language.

Neat syntax overall but it's not clear what it makes more succinct than the equivalent `elif` statements.

Agreed regarding the "or" - rejecting consistency here just because other languages do it differently is weird.

> it's not clear what it makes more succinct than the equivalent `elif` statements

But pattern matching is shorter than if-else in many cases and can actually differentiate between structures which makes it very flexible. It's like switch-case should have been from the start imho.

As an example, in Rust I often do comparisons between certain values by simply matching a tuple of them:

    match (foo, bar) {
        (x, x) => true, // foo == bar
        (Foo::VariantA(42), _) => unreachable!(), // has to be a bug
        (Foo::VariantA(a),  _) => a < 0,
        _ => false,
    }

This is of course a rather simple example, but I hope it still conveys what I like so much about this kind of feature. It doesn't do more than an if-else chain, but under the right circumstances it really shines. Just like list comprehensions don't add any new functionality, but the filtering and mapping features are often simply more expressive for what you want to do.

Although I'm not sure what to think of Python's preference to put the condition and code in different lines; maybe that's optional, which could make it more succinct when the situation permits it.

Reminds me of Window, which has keyboard input: https://github.com/lukeb42/window https://github.com/lukeb42/emissary

Talk more about what regulatory pressures can be applied to help these companies evolve:

https://theguardian.com/sustainable-business/2017/jul/10/100...

All libraries extend their language with new features.

A lot of the proposed value-add seems like the authors aren't aware the built-in `type()` can dynamically modify class definitions.

Getting rid of `hex(id(self))` in `__repr__` is regressive UX.

@typedispatch seems like both a slow way of using 'isinstance()' and a FOMO C++ virtual function bloat.

What does typed dispatch have to do with virtual functions in C++? This type of dispatch happens at compile-time in C++ and has nothing to do with "bloat" or even virtual functions.

What's it offering that's more idiomatic than the `isinstance()` it breaks down to other than resembling virtual functions in C++?

What's costlier, the new stack frames plus conditional for a decorator or the `elif isinstance()`s in one function definition?

How does a programmer reference the correct function definition by name if they're using @typedispatch instead of `isinstance()`?

I get the feeling that you don't know what virtual functions in C++ are.

I'd suggest you stop comparing typed dispatch to virtual functions in C++, because they have nothing in common. If you want to draw parallels, make sure to use a suitable analog.

I'm thinking of templates, if that helps.

<Aramaki> What do you mean I bricked my device?

I'm a huge fan of your book. Is there anything you'd add in a revised edition 20 years after publication?

Thanks ... I really appreciate the kind words. MIT Press has repeatedly tried to get me to do a 2nd edition and while it was tempting, I always ultimately decided that it was better to keep doing new things. Although, much to my surprise, a Japanese edition of the book just came out this year so there still seems to be some interest.

But that said, I am working on another book now that is meant to be a more accessible successor to CBofN and something of a computational "theory of everything else". I'm about halfway done, but the it's hard to write with the distraction of living in this bizarre timeline of ours.

Can you believe that’s the most exciting news I’ve heard in the past six months?

Yikes! I guess I better finish it now. Although, you should prepare to be bitterly disappointed because the next book will have something to piss off almost everyone (not by design, it's just that simultaneously seeking breadth, depth, and readability will always fall short on at least on dimension).

This looks excellent. Thank you.

Can we use asyncio to update multiple charts simultaneously / at arbitrary intervals?

Wouldn't it be better if Jupyter absorbed this API for its dashboards?