It is true that Python's typing and async support feels like someone adding extension to a house that was built 50 years ago.

After having used it two weeks ago for the first time: it feels as though async support in Python is basically a completely parallel standard library that uses the same python syntax with extra keywords all over the place. It's like if building code compliance required your 50 year old house to be updated have a wider staircase with deeper steps but you wanted to do so without affecting the existing stairs, so now you just have two staircases which are a little bit different and it feels like it takes up space unnecessarily.

I had to look for async versions of most of what I did (e.g. executing external binaries) and use those instead of existing functions or functionality, meaning it was a lot of googling "python subprocess async" or "python http request async".

If there were going to be some kind of Python 4.x in the future, I'd want some sort of inherent, goroutine-esque way of throwing tasks into the ether and then waiting on them if you wanted to. Let people writing code mark functions as "async'able", have Python validate that async'able code isn't calling non-async'able code, and then if you're not in an async runloop then just block on everything instead (as normal).

If I could take code like:

    def get_image(image):
        return_code = subprocess.check_call(["docker", "pull", image])
        if return_code:
            raise RuntimeError("idk man it broke")

    result = get_image(imagename)
    print(result)

    def get_image(image):
        return_code = subprocess.check_call(["docker", "pull", image])
        if return_code:
            raise RuntimeError("idk man it broke")

    result = async get_image(imagename)
    print(result)

Man, what a world that would be.