[lijok]

Tools like this rub me the wrong way.

We have well established conventions like prefixing private modules and symbols with an underscore, or declaring your public interfaces in the __init__.py file, but the Python developer decries it as "busywork", "weird" and "hard to read", so we instead use tools like this.

We can manage dependencies with protocols, a type checker and generally following SOLID principles, but the Python developer decries it as "too indirect and convoluted", so we instead use tools like this.

This is more commentary on the Python developer than this tool. Tach looks great.

[0x63_Problems]

Co-author here, I can understand where you're coming from!

Part of the philosophy here is that the tools and techniques you're describing can (and should) be used diligently to solve this problem, and Tach is often a complement to this approach.

The benefit of centralizing the concern into a single tool, and often a single config file, is that teams get better documentation, earlier feedback (in-editor vs. code review), and more visibility when planning new development. Teams also get to choose _how_ they would like to satisfy Tach's config, and other teams can still rely on the same guarantees due to Tach's static checks.

[echelon]

> We have well established conventions like prefixing private modules and symbols with an underscore, or declaring your public interfaces in the __init__.py file,

The language doesn't enforce them, so they may as well not exist. See: python dependency management.

> This is more commentary on the Python developer than this tool.

100%. Python has become an unstructured Wild West, perhaps even worse than modern JavaScript. The "Zen of Python" is a bold faced lie.

Python has incredible use cases. It blends together different disciplines effectively. But perhaps we should ask ourselves whether or not it's a language suitable for writing large monoliths in.

[lijok]

> The language doesn't enforce them, so they may as well not exist. See: python dependency management.

I see your point. You can enforce them with mypy by declaring your exports in your __init__.py file, using the `as` aliasing method or using `__all__`: https://mypy.readthedocs.io/en/stable/command_line.html#cmdo....

[SalmoShalazar]

The conventions are widely used and Python is used successfully in numerous “large monoliths”. Saying that the conventions may as well not exist if they’re not enforced is demonstrably nonsense.

[globular-toast]

It depends on your team. If the whole team "gets it" then things will be fine. But if you've got a team with juniors or people happy to do whatever crap they or ChatGPT can come up with to make things work then it doesn't.

[goosejuice]

That says more about your process as a swe org than the technology you're using.

[globular-toast]

That you'd use a tool or a language to help you?