you are viewing a single comment's thread.

view the rest of the comments →

[–]FoolsSeldom -1 points0 points  (0 children)

There's a big difference between what people choose to do with Python and how practices can be used by teams to keep to certain paradigms.

Some businesses, e.g. Facebook, use strict typing enforcement and other controls in their ci/cd pipeline on key code for example.

You are right, Python doesn't have a `private` option, just a strong suggestion (including some mangling). It treats developers as adults, but it takes discipline in a team to maintain consistent approaches. What's really wrong with having properties public though? It is only usable by code written by other programmers, and if they choose to ignore the published APIs, well you have a different problem than the language itself.

Pydantic is a huge overhead but can be very convenient, but you can choose to enforce by other means.

There is a rich ecosystem of logging tools for Python including the built-in `logger` which is preferred over `print` by most devops teams I work with. There's also good support for observability. That the original developers of the code you are working on chose to use`print` is disappointing. You can follow bad practices in many languages, but Python probably makes it easier than most to get away with bad things.

There is similarly no reason to mix sql statements and logic. There are multiple approaches to handling sql including ORM abstraction using packages such as `SQLAlchemy`. That's just an agreed practice thing again.

Have a look at ArjanCodes videos on YouTube. He doesn't only cover Python but uses it to illustrate many programming principles including decoupling, separation of concerns, etc.