3 ms·

> The real story is that Python is designed to be maximally dynamic -- you can monkey-patch methods at runtime, replace builtins, change a class's inheritance

> The real story is that Python is designed to be maximally dynamic -- you can monkey-patch methods at runtime, replace builtins, change a class's inheritance chain while instances exist -- and that design makes it fundamentally hard to optimize. ... > 4 bytes of number, 24 bytes of machinery to support dynamism. a + b means: dereference two heap pointers, look up type slots, dispatch to int.__add__, allocate a new PyObject for the result (unless it hits the small-integer cache), update reference counts. Would Python be a lot less useful without being maximally dynamic everywhere? Are there domains/frameworks/packages that benefit from this where this is a good trade-off? I can't think of cases in strong statically typed languages where I've wanted something like monkey patching, and when I see monkey patching elsewhere there's often some reasonable alternative or it only needs to be used very rarely.

LtWorf 7mo ago
I've used a library that patches the zipfile module to add support for zstd compression in zipfiles. In python3.14 the support is there, but 2 years ago you could just import this library and it would just work normally.
NeutralForest 7mo ago
There are some use cases for very dynamic code, like ORMs; with descriptors you can add attributes + behavior at runtime and it's quite useful. Anyways, breaking metaprogramming and more dynamic features would mean python 4 and we know how 2 -> 3 went. I also don't think it's where the core developers are going. Also also, there are other things I'd change before going after monkey patching like some scoping rules, mutable defaults in function attributes, better async ergonomics, etc.
bloaf 7mo ago
I've always thought the flexibility should allow python to consume things like gRPC proto files or OpenAPI docs and auto-generate the classes/methods at runtime as opposed to using codegen tools. But as far as I know, there aren't any libraries out there actually doing that.
- skeledrew 7mo ago
  But it's an fairly easy build if you want any of that.
- haimez 7mo ago
  Generating code at runtime is often an anti-goal because you can’t easily introspect it. “Build-time” generation gives you that, but print often choose to go further and check the generated code to source control to be able to see the change history.
  - bloaf 7mo ago
    But for things like e.g. DAG systems, it would be great to be able to upload a new API definition and have it immediately available instead of having to recompile anything in the backend.
    - notmarkeloff 7mo ago
      [dead]
adamzwasserman 7mo ago
The dynamism exists to support the object model. That's the actual dependency. Monkey-patching, runtime class mutation, vtable dispatch. These aren't language features people asked for. They're consequences of building everything on mutable objects with identity. Strip the object model. Keep Python. You get most of the speed back without touching a compiler, and your code gets easier to read as a side effect. I built a demo: Dishonest code mutates state behind your back; Honest code takes data in and returns data out. Classes vs pure functions in 11 languages, same calculation. Honest Python beats compiled C++ and Swift on the same problem. Not because Python is fast, but because the object model's pointer-chasing costs more than the Python VM overhead. Don't take my word for it. It's dockerized and on GitHub. Run it yourself: honestcode.software, hit the Surprise! button.
- deleted 7mo ago
  [deleted]
- adamzwasserman 7mo ago
  Correction. I copied some incorrect values from my test harness. So Honest Python does NOT beat Dishonest Swift. But it does beat the pants off of JS/TS on V8 which is quite the surprise. Also in the surprise category is that Honest Java is more than 2x faster than dishonest c++.

LtWorf 7mo ago

I've used a library that patches the zipfile module to add support for zstd compression in zipfiles. In python3.14 the support is there, but 2 years ago you could just import this library and it would just work normally.

NeutralForest 7mo ago

There are some use cases for very dynamic code, like ORMs; with descriptors you can add attributes + behavior at runtime and it's quite useful. Anyways, breaking metaprogramming and more dynamic features would mean python 4 and we know how 2 -> 3 went. I also don't think it's where the core developers are going. Also also, there are other things I'd change before going after monkey patching like some scoping rules, mutable defaults in function attributes, better async ergonomics, etc.

bloaf 7mo ago

I've always thought the flexibility should allow python to consume things like gRPC proto files or OpenAPI docs and auto-generate the classes/methods at runtime as opposed to using codegen tools. But as far as I know, there aren't any libraries out there actually doing that.

skeledrew 7mo ago
But it's an fairly easy build if you want any of that.
haimez 7mo ago
Generating code at runtime is often an anti-goal because you can’t easily introspect it. “Build-time” generation gives you that, but print often choose to go further and check the generated code to source control to be able to see the change history.
- bloaf 7mo ago
  But for things like e.g. DAG systems, it would be great to be able to upload a new API definition and have it immediately available instead of having to recompile anything in the backend.
  - notmarkeloff 7mo ago
    [dead]

adamzwasserman 7mo ago

The dynamism exists to support the object model. That's the actual dependency. Monkey-patching, runtime class mutation, vtable dispatch. These aren't language features people asked for. They're consequences of building everything on mutable objects with identity. Strip the object model. Keep Python. You get most of the speed back without touching a compiler, and your code gets easier to read as a side effect. I built a demo: Dishonest code mutates state behind your back; Honest code takes data in and returns data out. Classes vs pure functions in 11 languages, same calculation. Honest Python beats compiled C++ and Swift on the same problem. Not because Python is fast, but because the object model's pointer-chasing costs more than the Python VM overhead. Don't take my word for it. It's dockerized and on GitHub. Run it yourself: honestcode.software, hit the Surprise! button.

deleted 7mo ago
[deleted]
adamzwasserman 7mo ago
Correction. I copied some incorrect values from my test harness. So Honest Python does NOT beat Dishonest Swift. But it does beat the pants off of JS/TS on V8 which is quite the surprise. Also in the surprise category is that Honest Java is more than 2x faster than dishonest c++.