I completely agree with you on all points. It's terrifying to see these things you've described playing out.

Sorry if I've got this wrong, but wouldn't the first example behave the same way in Javascript as well? The function parent() "awaits" the completion of child(), so it wouldn't be possible to interleave the print statements.

The example from this StackOverflow question might be a better demonstration: https://stackoverflow.com/q/63455683

The whole article is bit of a mess. Like this thing:

> My mutation block contained no awaits. The only awaits happened before acquiring the lock. Therefore:

> * The critical section was atomic relative to the event loop.

> * No other task could interleave inside the mutation.

> * More locks would not increase safety.

That is exactly the same as with e.g. JS. I'm sure there are lot of subtle differences in how Python does async vs others, but the article fails to illuminate any of it; neither the framing story nor the examples really clarify anything

If we were to compare this to the JS world, it seems Python’s async is closer to Babel-style generator-based coroutines [1] than to JavaScript’s async/await execution model.

[1] https://babeljs.io/docs/babel-plugin-transform-async-to-gene...

You haven't got it wrong, the first example in the article behaves the same in JS, see https://jsfiddle.net/L5w2q1p7/.

I think in JS it's easier to see because of the correspondence between Promises and async/await.

So in your example the behavior is much more obvious if you sort of desugar it as

  async function parent() {
      print("parent before");
      const p = child();
      await p
      print("parent after");
  }

> as a consumer I could care less if you put your soul and years into producing art vs the one I can get a lot of today and now especially when there is virtually no difference in quality

as a fellow consumer I care a lot actually

This is awesome, I loved the interactivity!

This article is awesome, your writing is super approachable and the interactive demos are really cool. I also appreciate the background on how you got into doing this sort of thing.

Thank you! Really appreciate it

I think the \unicode CSS injection used here was reported to the MathJax library a few months ago - https://github.com/mathjax/MathJax/issues/3129

This isn't true, even if you define your own types/classes you still can't add them together willy nilly unless you (or a superclass) explicitly defined an addition operator. The Python language itself will never implicitly coerce a type for you, not even for floating point and integer addition. [0]

[0] https://www.pythonmorsels.com/type-coercion/

You're right. Classes don't even provide such operators by default:

  >>> class Foo:
  ...     ...
  ...
  >>> class Bar:
  ...     ...
  ...
  >>> a = Foo()
  >>> b = Bar()
  >>> a+b
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for +: 'Foo' and 'Bar'

If anything, the complaint is that pre-type-hinted Python was too quick to raise a TypeError without helping you know what types it was expecting. The only case I can think of where it was too lenient was where Python 2 conflated strings and bytes. That change was 90% of the pain of the Python 3 upgrade, and now they're different types.

I was speaking generally not specifically about addition. If you create new types and especially new operations on those types, then it will be up to you to add runtime "type checks" to avoid other failures. Try defining equality for a Point class for an example.

This is something I think is overlooked very often. I feel like a constant narrative I hear is that censoring media like this is a new-fangled concept when in reality this has been standard practice forever.