3 ms·

I'm diving back into python after being mostly away for the better part of a decade having built high scale, highly available systems in Go during that time (in

I'm diving back into python after being mostly away for the better part of a decade having built high scale, highly available systems in Go during that time (including migrating several projects from python and perl to go). Being suddenly back in python is jarring. So much inheritance - abstract base classes and multiple inheritance via mixins, strange coupling in tests via over use of mocking and patching, and a reliance on method overloading to do magic things like make a field actually call out to the database on usage causing strange behavior that is unexpected. I miss Go and I will be pushing for it via the strangler pattern to bring productivity and sense to this project.

lemagedurage 3y ago
Python code typically doesn't and shouldn't rely heavily on inheritance. It sounds like you're working on non-idiomatic Python code. Bad luck.
- tgv 3y ago
  Django typically does this.
  - pphysch 3y ago
    In a lot of cases it is necessary complexity, between overloading the dot operator, wrapping SQL, and supporting multiple database backends. There is a fair bit of bloat, though.
  - ShamelessC 3y ago
    Indeed. It's quite off-putting.
- xwowsersx 3y ago
  Do you mean that the hierarchies don't tend to be very deep in Python? I don't tend to have deep inheritance hierarchies in Python, but I don't tend to have that in really any language I use. If you mean Python code doesn't tend to use inheritance in general, I'm not sure that's true. Django, DRF, the ML/DS packages, etc. all seem to use inheritance as much as any other language...I think? Maybe you're contrasting to those endlessly deep hierarchies you might find in Java? Otherwise, I'm just not sure what the basis is for saying you shouldn't rely on inheritance in Python, given that it is a first-class citizen due to its object-oriented programming model.
- Ringz 3y ago
  True. Thanks for your comment.
bb88 3y ago
I was thrust into a go project after a decade of python. The most jarring thing besides the 3rd party panics, was the idiom that nils are typed. This was different than python, java, JavaScript, c, c++, etc. Variable loop scoping is also weird. Writing unit tests is 10 times harder than python. Go statically links everything, and just that seems like going back 30 years in software development. Any security in a dependency means a total recompile and redeployment. In C land you would just update the affected library.
- arp242 3y ago
  Python has complex mechanisms to avoid depending on "whatever random stuff is in /usr/lib/python$v/site-packages" like pyenv and whatnot. Clearly that approach comes with a lot of downsides, too. Most newer languages avoid this pattern, including Rust, Zig, and probably others, and languages that don't tend to have workarounds; e.g. npm, bundle, etc. all use a "local" installation by default. And while security problems are of course still a thing, there are a lot fewer of them than in C. Even in C it's not as bad as in "buffer overflow of the week" like in the 90s. It's that argument that's 30 years out of date.
- pharmakom 3y ago
  If you have CI/CD then rebuild and deploy isn’t a big deal. If you’re mutating running systems in an uncontrolled way you’re probably doing it wrong
- selfmodruntime 3y ago
  The reason that we have static linking is because it's not "you" updating the affected library, it's more often than not the package manager and more often than not entirely out of your control.

lemagedurage 3y ago

Python code typically doesn't and shouldn't rely heavily on inheritance. It sounds like you're working on non-idiomatic Python code. Bad luck.

tgv 3y ago
Django typically does this.
- pphysch 3y ago
  In a lot of cases it is necessary complexity, between overloading the dot operator, wrapping SQL, and supporting multiple database backends. There is a fair bit of bloat, though.
- ShamelessC 3y ago
  Indeed. It's quite off-putting.
xwowsersx 3y ago
Do you mean that the hierarchies don't tend to be very deep in Python? I don't tend to have deep inheritance hierarchies in Python, but I don't tend to have that in really any language I use. If you mean Python code doesn't tend to use inheritance in general, I'm not sure that's true. Django, DRF, the ML/DS packages, etc. all seem to use inheritance as much as any other language...I think? Maybe you're contrasting to those endlessly deep hierarchies you might find in Java? Otherwise, I'm just not sure what the basis is for saying you shouldn't rely on inheritance in Python, given that it is a first-class citizen due to its object-oriented programming model.
Ringz 3y ago
True. Thanks for your comment.

bb88 3y ago

I was thrust into a go project after a decade of python. The most jarring thing besides the 3rd party panics, was the idiom that nils are typed. This was different than python, java, JavaScript, c, c++, etc. Variable loop scoping is also weird. Writing unit tests is 10 times harder than python. Go statically links everything, and just that seems like going back 30 years in software development. Any security in a dependency means a total recompile and redeployment. In C land you would just update the affected library.

arp242 3y ago
Python has complex mechanisms to avoid depending on "whatever random stuff is in /usr/lib/python$v/site-packages" like pyenv and whatnot. Clearly that approach comes with a lot of downsides, too. Most newer languages avoid this pattern, including Rust, Zig, and probably others, and languages that don't tend to have workarounds; e.g. npm, bundle, etc. all use a "local" installation by default. And while security problems are of course still a thing, there are a lot fewer of them than in C. Even in C it's not as bad as in "buffer overflow of the week" like in the 90s. It's that argument that's 30 years out of date.
pharmakom 3y ago
If you have CI/CD then rebuild and deploy isn’t a big deal. If you’re mutating running systems in an uncontrolled way you’re probably doing it wrong
selfmodruntime 3y ago
The reason that we have static linking is because it's not "you" updating the affected library, it's more often than not the package manager and more often than not entirely out of your control.