Best Practices for Internal Package Structure

[Ethan Furman]

On 04/04/2016 06:43 PM, Steven D'Aprano wrote:
> On Tue, 5 Apr 2016 02:47 am, Josh B. wrote:
>
>> My package, available at https://github.com/jab/bidict, is currently laid
>> out like this:
>>
>> bidict/
>> ├── __init__.py
>> ├── _bidict.py
>> ├── _common.py
>> ├── _frozen.py
>> ├── _loose.py
>> ├── _named.py
>> ├── _ordered.py
>> ├── compat.py
>> ├── util.py
>
>
> 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.

Agreed.


> (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

Yup... well, actually you could just stick it in __init__.py.

> Unless you are getting some concrete benefit from a package structure, you
> shouldn't use a package just for the sake of it. Even if the code doubles
> in size, to 1000 lines, that's still *far* below the point at which I
> believe a single module becomes unwieldy just from size. At nearly 6500
> lines, the decimal.py module is, in my opinion, *almost* at the point where
> just size alone suggests splitting the file into submodules. Your module is
> nowhere near that point.

Well, there should be one more module:

   test.py

So in total, two files

bidict/
|-- __init__.py
|-- test.py

will do the trick.  Oh, and you want a README, LICENSE, a doc file.  And 
that should do it.  :)

--
~Ethan~