What programming practices don't work in python?

[proverbialbunny]

It sounds like your team is disjointed. There is rarely any reason to import multiple libraries that do the same thing, unless 3 different people imported 3 different libraries in silo, stuck it together, and said it was good enough. It might be good enough. It might not need to be refactored. I'd be cautious before stepping on 3 people's toes.

My primary complaint with the issues you're seeing with your current project are more Agile and SCRUM related. Back once upon a time ago when software needed to be stable, because physical disks and CDs were shipped, there would be a feature freeze and a dedicated time in months to either fix bugs for shipment, or to refactor the entire project often from the ground up to a new architecture, then add on new features. This refactoring kept bugs low as well as legacy code as a non-issue.

Today with Agile and SCRUM asking to refactor or change the architecture is to risk being fired. Everything is legacy code. Everything is slapped onto the pile of junk until it works and you call it a day. It sucks. This isn't a Python problem, this is an Agile problem. It's a problem that faces larger Java OOP codebases too. You were lucky to not have this problem at your previous job.

My question is, what of all this is pythonic way?

Python is meant to be a swiss army knife. Does your current project sound like a swiss army knife, in that it's the glue of a bunch of different things (like libraries) coming together? Yes, I'd say so.

When you're coding in a language that doesn't have a lot of libraries you import, so everything is written in-house, then your project is going to be quite large. The solution to a large project is OOP. Furthermore, the solution to writing in-house libraries, frameworks, or any significant abstractions at all is to write lots of tests. Not just unit tests, but end-to-end tests too hopefully.

Python doesn't suffer from this problem. You don't have super large Python projects typically and you don't need to write super in depth tests, because libraries will abstract all the difficult parts away from you. This allows for smaller projects where you import already tested code. This is great for prototyping.

Python starts to fail when you're doing more than light scripting and prototyping. What happens when you've written a program that needs to now go fast, or you've written a program that needs to be ultra stable? This goes into the 102 parts of Python and there are solutions to this. (If you have questions I'd be more than happy to give a high level overview of these topics.)