Best Practices for Internal Package Structure

[Ethan Furman]

On 04/05/2016 10:38 AM, Sven R. Kunze wrote:
> On 05.04.2016 03:43, Steven D'Aprano wrote:
>> The purpose of packages isn't enable Java-style "one class per file"
>> coding,
>> especially since *everything* in the package except the top level
>> "bidict"
>> module itself is private. bidict.compat and bidict.util aren't flagged as
>> private, but they should be, since there's nothing in either of them that
>> the user of a bidict class should care about.
>>
>> (utils.py does export a couple of functions, but they should be in the
>> main
>> module, or possibly made into a method of BidirectionalMapping.)
>>
>> Your package is currently under 500 lines. As it stands now, you could
>> easily flatten it to a single module:
>>
>> bidict.py
>
> I don't recommend this.
>
> The line is blurry but 500 is definitely too much. Those will simply not
> fit on a 1 or 2 generous single screens anymore (which basically is our
> guideline). The intention here is to always have a bit more of a full
> screen of code (no wasted pixels) while benefiting from switching to
> another file (also seeing a full page of other code).

I do.  I have modules ranging from 1300+, 1800+, and nearly 10,000 
lines.  The only one I'm considering refactoring is the 10,000 line one; 
the others are just fine and would only suffer from being split up.

Possibly a good rule of thumb:  If a module is useful on its own (a 
bunch of utilities, or a bunch of data types, or a specific class with 
lots of utilities just for that class) then it's okay by itself; 
otherwise, combine it with the module it's used in.

--
~Ethan~