Organizing a Python project
Gabriel Genellina
gagsl-py2 at yahoo.com.ar
Sun May 25 22:51:48 EDT 2008
En Sun, 25 May 2008 19:46:50 -0300, Casey McGinty <casey.mcginty at gmail.com> escribió:
> On Sat, May 24, 2008 at 2:11 PM, Gabriel Genellina <gagsl-py2 at yahoo.com.ar>
> wrote:
>
>> > 2. In the top of your package directory it is typical to have a module
>> name
>> > '_package.py'. This is ideally where the main command line entry point
>> for
>> > the package code should be placed.
>>
>> Why the underscore? And I usually don't put executable scripts inside a
>> package - I consider them just libraries, to be imported by other parts of
>> the application.
>> It's easier to test too when your tests *and* the application code are
>> external to the package itself.
>>
>
> Ok, guess using the '_package' name is not very common. I saw it used by the
> dbus module. My whole concern here is that using a script will fragment your
> application code across the file system. I would prefer to have it all in a
> single spot. So I still like they idea of keeping most of application code
> (argument parsing, help output, initialization) inside of the package. The
> '_' should indicate that any other modules using your package should import
> that module.
Not only using _package isn't very common - it goes against the general rule (this one very well established) that names with a single leading _underscore are private (implementation details). So I would *not* expect to import _package as a rule.
I don't think splitting the application in two or more parts ("fragmentation" as you call it) is a bad thing by itself; the package will likely appear under some-python-directory/site-packages/your_package_name (where anyone would search for it) and the executable scripts on /usr/bin (where anyone would likely search for it too).
--
Gabriel Genellina
More information about the Python-list
mailing list