Show HN: Strict interfaces and dep management for Python, written in Rust (opens in new tab)

In large codebases you can have a problem where people randomly import things from different locations leading to a host of issues including circular import issues.

For example someone finds a convenient helper function in "my_thing.foo.bar.helpers" and imports it but you don't want that dependency between those modules and the helper function was not intended to be used outside of that module.

In Python this problem is especially severe because there is no native module encapsulation mechanism other than a weak conventio of using the underscore prefix.

A tool like this helps you enforce "intentional" module boundaries so modules can't randomly reach into each other to import things. You will be forced to consider an intentional modular design where the helpers that are needed by many things are separated out and other things are allowed to import from it.

borplk hit this right on the head - the public/private distinction not sufficiently nuanced enough to handle the requirements of more complex codebases.

To put your example in other words, I simply want baz scoped to foo. baz may be public for all members and sub-modules of foo, but external uses of baz outside of foo would create brittle and unwanted dependencies across my codebase.