organizing your scripts, with plenty of re-use

Gabriel Genellina gagsl-py2 at yahoo.com.ar
Sat Oct 10 18:44:18 CEST 2009


En Sat, 10 Oct 2009 05:57:08 -0300, Steven D'Aprano  
<steve at remove-this-cybersource.com.au> escribió:
> On Fri, 09 Oct 2009 16:37:28 -0700, Buck wrote:
>
>> Here's a scenario. A user does a cvs checkout into some arbitrary
>> directory and sees this:
>>
>> project/
>> +-- python/
>>     +-- animals.py
>>     +-- mammals/
>>         +-- horse.py
>>         +-- otter.py
>>     +-- reptiles/
>>         +-- gator.py
>>         +-- newt.py
>>     +-- misc/
>>         +-- lungs.py
>>         +-- swimming.py
>>
>> These are all runnable scripts that "just work" with no extra effort or
>> knowlege, both in the testing scenario above, and for normal users that
>> run it from some central location (maybe "/tools/mycompany/bin/
>> mammals").
>>
>> The frustrating thing, for me, is that all these requirements are met if
>> you leave the scripts in jumbled into a flat directory.
>
> I bet that's not true. I bet that they Just Work only if the user cd's
> into the directory first. In other words, if you have all your scripts in
> the directory /tools/mycompany/bin/scripts, this will work:
>
> $ cd /tools/mycompany/bin/scripts
> $ animals.py
>
> but this won't:
>
> $ cd /home/username
> $ /tools/mycompany/bin/scripts/animals.py
>
>
> In the first case, it works because the current working directory is
> included in the PYTHONPATH, and all the modules you need are there. In
> the second, it doesn't because the modules aren't in either the current
> directory or any other directory in the PYTHONPATH.
>
> That's my prediction.

Mmm, I predict you won't have much success in your new fortune teller  
career... :)
You got it backwards. At least on Windows, the current directory *isn't*  
on the Python path, but the directory containing the script *is* included.
So both alternatives above work.

>> As soon as you
>> start organizing things, you need a good amount of boilerplate in each
>> script to make things work anything like they did with the flat
>> directory.
>
> You shouldn't need that much boilerplate. A little, perhaps, but not that
> much.
>
>
> project/
> +-- animal
> +-- mammal
> +-- reptile
> +-- backend/
>     +-- __init__.py
>     +-- animals.py
>     +-- mammals/
>         +-- __init__.py
>         +-- horse.py
>         +-- otter.py
>     +-- reptiles/
>         +-- __init__.py
>         +-- gator.py
>         +-- newt.py
>     +-- misc/
>         +-- __init__.py
>         +-- lungs.py
>         +-- swimming.py
>
>
> where the front end is made up of three scripts "animal", "mammal" and
> "reptile", and the entire backend is in a package. Each front end script
> manages a small amount of boilerplate, something like this:

[code omited]

You need even less code. In fact, you don't need any boilerplate code.  
This Just Works (tm):

<code>
#!/usr/bin/python

 from backend import animals
animals.main()
</code>

That's all. No need to set PYTHONPATH, nor alter sys.path, nor install the  
whole tree in a specific place.
The good thing is that, if the backend package is properly installed  
somewhere in the Python path, and the animal script is copied onto any  
suitable place, it still works with no modifications.

-- 
Gabriel Genellina




More information about the Python-list mailing list