On Wed, 6 Apr 2016 03: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).
Are you serious that you work under the restriction that the entire file must fit on a single screen? Or at most two pages? So basically you've moved the burden of scrolling up and down a single file to find the code you want into searching through the file system to find the code that you want. I don't see this as an advantage. > 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 don't understand this benefit. How does exceeding 1-2 pages of code in a file prevent you from opening a second file in a separate window? As we speak, I have 28 text editor windows open. Not all of them are Python code, but among those which are, I have: 216 lines 157 lines 906 lines 687 lines 173 lines 373 lines 402 lines 6409 lines 509 lines 97 lines 163 lines 393 lines 1725 lines 25 lines I have no problem with working with multiple file despite exceeding the limit, so I don't understand the purpose of this guideline. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
