that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented.

What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about.

A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not.

Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.