On 16 dic, 12:28, "Stuart D. Gathman" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list