4 ms·

> If a class is so gargantuan as to require multiple files IMHO anything that doesn't fit in one screen is "gargantuan" > If you import in a namespace (`from

> If a class is so gargantuan as to require multiple files IMHO anything that doesn't fit in one screen is "gargantuan" > If you import in a namespace (`from foo import module`, `from bar import other_module`), you can have `module.module`, `other_module.module` Which looks ugly and feels a nasty headache if you want to maintain intuitive vision of your code and dependencies structure. > It's also possible to, generally speaking, have private submodules within one larger module. You can do this with `__init__.py` by importing the various submodules, explicitly re-exporting I know but even reading this paragraph hurts. Too much mess to manage manually.

joshuamorton 8y ago
>IMHO anything that doesn't fit in one screen is "gargantuan" This is a bit of an odd definition, but sure (I've seen C++ files whose imports alone were gargantuan under your definition). I just looked through a production python application, and it there were 2 non-test classes that were more than 100 lines long. Both were relatively verbose (well commented, use type hints so argument lists use significant vertical space, etc.) In general, it seems like you're limiting yourself to, with the necessary boilerplate, one or two functions in any file that isn't "gargantuan". This makes it needlessly difficult to understand the structure of your applications since you are forced to split related logic up among multiple files. This, more than screen length or the import syntax, makes it much, much harder to "maintain intuitive vision of code and dependencies structure" as you say. >Which looks ugly and feels a nasty headache if you want to maintain intuitive vision of your code and dependencies structure. Not at all. It's more explicit about the dependency structure (`module.method(args)` at a call site gives you a much better idea of the structure than just `method(args)`), and so makes it significantly easier to maintain an intuitive vision of the code and dependencies. It's incalculably easier to understand dependency structure when using the `import module` syntax than `from module import Class` or `from module import *`. So much so that the former allows reliable, large scale refactorings without any runtime information. The others, as you correctly recognize, do not. >I know but even reading this paragraph hurts. Too much mess to manage manually. Then don't! You don't need to. It's really only necessary for truly public/widely used APIs (like numpy) where understanding the internal structure of the module is not worth it for the average user.
- qwerty456127 8y ago
  > Then don't! You don't need to. It's really only necessary for truly public/widely used APIs (like numpy) where understanding the internal structure of the module is not worth it for the average user. I mean for the library developer, not for the user.

joshuamorton 8y ago

>IMHO anything that doesn't fit in one screen is "gargantuan" This is a bit of an odd definition, but sure (I've seen C++ files whose imports alone were gargantuan under your definition). I just looked through a production python application, and it there were 2 non-test classes that were more than 100 lines long. Both were relatively verbose (well commented, use type hints so argument lists use significant vertical space, etc.) In general, it seems like you're limiting yourself to, with the necessary boilerplate, one or two functions in any file that isn't "gargantuan". This makes it needlessly difficult to understand the structure of your applications since you are forced to split related logic up among multiple files. This, more than screen length or the import syntax, makes it much, much harder to "maintain intuitive vision of code and dependencies structure" as you say. >Which looks ugly and feels a nasty headache if you want to maintain intuitive vision of your code and dependencies structure. Not at all. It's more explicit about the dependency structure (`module.method(args)` at a call site gives you a much better idea of the structure than just `method(args)`), and so makes it significantly easier to maintain an intuitive vision of the code and dependencies. It's incalculably easier to understand dependency structure when using the `import module` syntax than `from module import Class` or `from module import *`. So much so that the former allows reliable, large scale refactorings without any runtime information. The others, as you correctly recognize, do not. >I know but even reading this paragraph hurts. Too much mess to manage manually. Then don't! You don't need to. It's really only necessary for truly public/widely used APIs (like numpy) where understanding the internal structure of the module is not worth it for the average user.

qwerty456127 8y ago
> Then don't! You don't need to. It's really only necessary for truly public/widely used APIs (like numpy) where understanding the internal structure of the module is not worth it for the average user. I mean for the library developer, not for the user.