5 ms·

Namespaces are great but Python’s module system being coupled to file system structure kinda sucks. You either have overly-granular modules with manageable file

Namespaces are great but Python’s module system being coupled to file system structure kinda sucks. You either have overly-granular modules with manageable files, or you end up with multi-thousand line files that present a reasonable module organization. Or the totally unreasonable granular module structure for reasonable files with a facade set of modules that just reexport things.

plq 4y ago
You can split your big module into modules inside a sub-package and import stuff in the __init__.py file from the submodules to present a nice interface to the library user. eg instead of: namespace.py class C1: class C2: do namespace/__init__.py from .c1 import C1 from .c2 import C2 namespace/c1.py class C1: namespace/c2.py class C2:
- eloisius 4y ago
  That’s what I described as the facade module approach.
- eesmith 4y ago
  What I don't like about this approach is how I'm supposed to refer to something by namespace.C1 but its repr is namespace.c1.C1. I would prefer if the repr reported its primary public API name, not its internal implementation location.
mikepurvis 4y ago
What's wrong with facade modules? That seems to be a pretty common pattern, and it allows you to decouple your filesystem structure from module structure while still giving someone reading the source a breadcrumb to follow. Quite apart from implementation challenges (eg, needing to parse every file in package upfront to know what's in there), how else would you see this working? Are there other interpreted languages that manage this indirection in a more elegant way than having some central file that supplies the mapping information?
- eloisius 4y ago
  There’s nothing wrong with it, per se, but it is more to maintain, and it’s a confusing indirection to downstream users that need to pry into your code to debug something. Ruby has its own problems, but I like that the modules are independent from the file that contains them. You can “reopen” a module and declare new classes or constants or whatever. You have freedom (and responsibility) to organize your files in a way that maps to module namespaces. The drawback is the `require “my_file”` doesn’t give you any hint about what you’re importing.
emidln 4y ago
You can organize your packages however you want if you write and register a new module loader.
throwaway892238 4y ago
The module system linked to file structure worked for Perl pretty well. Perl had this crazy idea that different authors should publish packages/modules with the same namespace, e.g. IO.pm <-- author: Larry Wall IO/File.pm <-- author: Me IO/Socket.pm <-- author: You IO/Socket/INET.pm <-- author: Larry Wall IO/Socket/INET/Daemon.pm <-- author: Me Simpler and encourages code reuse. Of course there is duplicate code in CPAN, but you really have to go out of your way to avoid an existing module that can do what you need.

plq 4y ago

You can split your big module into modules inside a sub-package and import stuff in the __init__.py file from the submodules to present a nice interface to the library user. eg instead of: namespace.py class C1: class C2: do namespace/__init__.py from .c1 import C1 from .c2 import C2 namespace/c1.py class C1: namespace/c2.py class C2:

eloisius 4y ago
That’s what I described as the facade module approach.
eesmith 4y ago
What I don't like about this approach is how I'm supposed to refer to something by namespace.C1 but its repr is namespace.c1.C1. I would prefer if the repr reported its primary public API name, not its internal implementation location.

mikepurvis 4y ago

What's wrong with facade modules? That seems to be a pretty common pattern, and it allows you to decouple your filesystem structure from module structure while still giving someone reading the source a breadcrumb to follow. Quite apart from implementation challenges (eg, needing to parse every file in package upfront to know what's in there), how else would you see this working? Are there other interpreted languages that manage this indirection in a more elegant way than having some central file that supplies the mapping information?

eloisius 4y ago
There’s nothing wrong with it, per se, but it is more to maintain, and it’s a confusing indirection to downstream users that need to pry into your code to debug something. Ruby has its own problems, but I like that the modules are independent from the file that contains them. You can “reopen” a module and declare new classes or constants or whatever. You have freedom (and responsibility) to organize your files in a way that maps to module namespaces. The drawback is the `require “my_file”` doesn’t give you any hint about what you’re importing.

emidln 4y ago

You can organize your packages however you want if you write and register a new module loader.

throwaway892238 4y ago

The module system linked to file structure worked for Perl pretty well. Perl had this crazy idea that different authors should publish packages/modules with the same namespace, e.g. IO.pm <-- author: Larry Wall IO/File.pm <-- author: Me IO/Socket.pm <-- author: You IO/Socket/INET.pm <-- author: Larry Wall IO/Socket/INET/Daemon.pm <-- author: Me Simpler and encourages code reuse. Of course there is duplicate code in CPAN, but you really have to go out of your way to avoid an existing module that can do what you need.