Best Practices for Internal Package Structure

Michael Selik michael.selik at gmail.com
Mon Apr 4 14:45:35 EDT 2016


On Mon, Apr 4, 2016 at 6:04 PM Sven R. Kunze <srkunze at mail.de> wrote:

> Hi Josh,
>
> good question.
>
> On 04.04.2016 18:47, 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
> >
> >
> > I'd like to get some more feedback on a question about this layout that
> I originally asked here: <
> https://github.com/jab/bidict/pull/33#issuecomment-193877248>:
> >
> > What do you think of the code layout, specifically the use of the _foo
> modules? It seems well-factored to me, but I haven't seen things laid out
> this way very often in other projects, and I'd like to do this as nicely as
> possible.
>

Using the _module.py convention for internals is fine, except that you have
few enough lines of code that you could have far fewer files. Why create a
package when you can just have a module, bidict.py?

I find it easier to find the right section of my code when I have just a
few files open rather than a dozen or so in different windows and tabs.



More information about the Python-list mailing list