Package vs. module

[Gabriel Genellina]

On 16 dic, 12:28, "Stuart D. Gathman" <stu... at bmsi.com> wrote:

> NOW, this is all very nice and modular. BUT, the original module was a
> single file, which could be run as a script as well as imported as a
> module. The script features provided useful command line functionality.
> (Using if __name__ == '__main__':).  Now that 'spf' is a package, the
> command line feature is gone!  Even using -m, I get:

Yes, a little sacrifice...

> Looking at getpass.py as advised, I see they put all the drivers in the
> module.  I could do that with spf.py, I suppose.  But I like how with the
> package, the driver code is not loaded unless needed.

That's good.

> One other idea I had was an arrangement like this:
>
> SPF/
>   pydns.py
>   dnspython.py
>
> spf.py
>
> This would keep the module as a single file usable from the command line,
> but still make driver available as separately loaded modules.
>
> So which of the three options,
>
> 1) single file module with all drivers, ala getpass
You've already seen that it's not a good option. getpass is different
in the sense that only one version should be available in a given
system, so it keeps trying alternatives until a candidate is found.

> 2) package that cannot be run directly from command line
> 3) single file module with associated driver package

I think that keeping demo/application code separate from the library
would be a good thing.
So, keep your library inside a package, and provide some external
scripts as example, demo, whatever.
You can instruct distutils to install each thing in the right place.

-- 
Gabriel Genellina