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~
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to