I suspect the same. People adopt Python because its clean syntax and REPL make the language approachable and easy to get started and then the huge library ecosystem helps you glue together (in a good way) powerful systems. But how many Python users and libraries actually use the language’s extremely dynamic runtime behavior? Something they’re paying for with a big performance penalty and surprising bugs.

Numpy uses magic methods (Python's version of operator overloading). Django uses metaclasses. Pytest dynamically rewrites assert statements using AST. I'd say it's pretty common, at least in libraries. I certainly depend on Python's dynamism when fully leveraging the REPL.

Indeed, these capabilities of the language are some of its strengths, even if we don't all trust ourselves to use them. The casual programmer doesn't know how or why numpy works, and we don't play with magic methods except out of curiosity. The people who do maintain numpy are using more formal methods to ensure its quality.

In the case of Python, the things that professional caliber programmers can use to extend its functionality, and the things that the rest of us can use to be productive, are the same language and are not hidden from one another. This is not the case in some languages of the past, e.g., you could use objects in Visual Basic but not build them without another language or eventually a special version.

Python's popularity has grown pretty steadily over decades. It retains users because of its merits and became popular in multiple niches more or less independently.

> While typing is dynamic, I rarely see this being used, perhaps with the exception of identifying empty variables with None. Most identifiers are born and die the same type. It would be interesting to see how much effect dynamic typing has on the rate of programming errors.

Dynamic typing and changing the type of a variable are orthogonal.

You can change a type with casting, coercion, transmutation, dynamic dispatch, downcasting, reflection, monkeypatching (i.e. simultaneosly using dynamic dispatch and downcasting and reflection). All of these methods are available in Rust, which is a statically typed language.

Some things that some people think are changing the type of a variable in Python is not what it seems, for example:

    # Python
    a = 1
    a = ['h','i'] # `a: int` is unchanged but gets implicitly shadowed by `a: list[str]`
    a[1] = "a"    # We're combining shadowing with weird and inconsistent scoping

translates to the following in Rust:

    // Rust
    #[allow(unused_mut, unused_variables)]
    {
        let mut a = 1;
        let mut a = ["h", "i"]; // Explicit shadowing
        a[1] = "a"; // We're simply calling a mutating operator
    }

Furthermore:

    # Python
    lst: Array[Any] = [1, "2", 3.0] # A heterogeneous list
    for elem in lst:
        print(elem);

translates to the following in Rust:

    // Rust
    // Below `dyn` has nothing whatsoever to do with dynamic typing.
    // ... it is just fluff having to do with the requirements of systems programming.
    // ... (Technically it means we're using vtables to do dynamic dispatch.)
    // ... The `Box` nonsense is more systems dev fluff having to do with memory allocation.
    // ... Of course in Rust, App devs often don't need to worry about such fluff because
    // ... lib devs should provide ergonomic API's, but I'm doing as close as
    // ... possible to a direct translation of the Pyhon code.
    #[allow(unused_mut)]
    let mut lst: Vec<Box<dyn Display>> = vec![
        Box::new(1),
        Box::new("1"),
        Box::new(1.0),
    ];
    for elem in lst {
        println!("{elem}");
    }

The one major difference between the Python code and Rust code above is that `Display` in Rust is a Rust trait (i.e. a typeclass) and typeclasses don't exist in Python.