[t43562]

I do think some module writers get overexcited about using some dynamic features and it can be hard to understand what's going on. On the other hand....

Dynamic languages let you do a lot of things with meta classes and monkey-patching that allow you to use a library without needing to build your own special version of it. With some C or C++ library that did something bad (like the logging one you mentioned) there's nothing for it but to rebuild it. With Python you may well be able to monkey patch it and live to fight another day.

It is great when you're dealing with 3rd party things that you either don't have the source code for or where you cannot get them to accept a patch.

[arw0n]

It has been a couple of years, but I was working on a rather complex RoR application and trying to fix a bug, where I had serious trouble understanding the underlying behavior. I went through the library docs, gave our code multiple screenings and was just stumped. - Turns out, we were monkey-patching an issue that was a also resolved a couple of years before, in a slightly different way than the library authors, and this was leading to very subtle issues down the line.

Now of course, we should have long removed the monkey-patch, or properly documented it somewhere, or I should have been more knowledgeable about Ruby and known that monkey-patching was a thing, but there's a reason why it is a pretty frowned upon practice.

[adastra22]

“Python lets me do horrifying things no one should ever do in production code” isn’t the flex you think it is.

[t43562]

Why should no-one ever do them? They're useful. :-) FastAPI uses this stuff to make itself easier to use for example. They're things I would have killed for when I was writing C++.