Best Practices for Internal Package Structure

[Michael Selik]

> On Apr 5, 2016, at 7:49 PM, Sven R. Kunze <srkunze at mail.de> wrote:
> 
>> On 05.04.2016 19:59, Chris Angelico wrote:
>> On Wed, Apr 6, 2016 at 3:38 AM, Sven R. Kunze <srkunze at mail.de> wrote:
>>>> 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).
>> Clearly this is a matter of opinion. I have absolutely no problem with
>> a 500-lne file. As soon as you force people to split things across
>> files, you add a new level of indirection that causes new problems.
> 
> Guidelines. No forcing.
> 
>> I'd rather keep logically-related code together rather than splitting
>> across arbitrary boundaries;
> 
> That's a good advice and from what I can see bidict adheres to that. ;)
> 
>> you can always search within a file for the bit you want.
> 
> If you work like in the 80's, maybe. Instead of scrolling, (un)setting jumppoints, or use splitview of the same file, it's just faster/easier to jump between separate files in todays IDEs if you need to jump between 4 places within 3000 lines of code.

When you made that suggestion earlier, I immediately guessed that you were using PyCharm. I agree that the decision to split into multiple files or keep everything in just a few files seems to be based on your development tools. I use IPython and SublimeText, so my personal setup is more suited to one or a few files.

>> When you split a file into two, you duplicate the
>> headers at the top (imports and stuff), so you'll split a 100-line
>> file into two 60-line files or so. Do that to several levels in a big
>> project and you end up with a lot more billable lines of code, but no
>> actual improvement.
> 
> Who cares about the imports? As I said somewhere else in my response, it's hidden from sight if you use a modern IDE. We call that folding. ;)
> 
> Who bills lines of code? Interesting business model. ;)
> 
>> I guess that's worth doing - lovely billable hours
>> doing the refactoring,
> 
> Refactoring is not just splitting files if that concept is new to you.
> 
> Refactoring it not an end to itself. It serves a purpose.
> 
>> more billable hours later on when you have to
>> read past the migration in source control ("where did this line come
>> from" gets two answers all the time), and more billable hours dealing
>> with circular imports when two fragments start referring to each
>> other. Sounds like a plan.
> 
> It appears to me as if you like messy code then. ;)
> 
> Best,
> Sven
> -- 
> https://mail.python.org/mailman/listinfo/python-list