organizing your scripts, with plenty of re-use

Gabriel Genellina gagsl-py2 at yahoo.com.ar
Tue Oct 13 14:14:53 EDT 2009


En Tue, 13 Oct 2009 13:28:05 -0300, Buck <workitharder at gmail.com> escribió:
> On Oct 12, 3:34 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
> wrote:
>> Quoting Steven D'Aprano  
>> (changing names slightly):
>>
>> """You would benefit greatly from separating the interface from
>> the backend. You should arrange matters so that the users see something
>> like this:
>>
>> project/
>> +-- animal
>> +-- mammal
>> +-- reptile
>> +-- somepackagename/
>>      +-- __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.""" [ignore the rest]
>>
>> By example, the `animal` script would contain:
>>
>>  from somepackagename import animals
>> animals.main()
>>
>> or perhaps something more elaborate, but in any case, the script  
>> imports  
>> whatever it needs from the `somepackagename` package.
>>
>> The above script can be run:
>>
>> a) directly from the `project` directory; this could be a checked out  
>> copy  
>>  from svn, or a tar file extracted in /tmp, or whatever. No need to  
>> install  
>> anything, it just works.
>>
>> b) alternatively, you may install somepackagename into site-packages  
>> (or  
>> the user site directory, or any other location along the Python path),  
>> and  
>> copy the scripts into /usr/bin (or any other location along the system  
>> PATH), and it still works.
>>
>> The key is to put all the core functionality into a package, and place  
>> the  
>> package where Python can find it. Also, it's a good idea to use  
>> relative  
>> imports from inside the package. There is no need to juggle with  
>> sys.path  
>> nor even set PYTHONPATH nor import __main__ nor play any strange games;  
>> it  
>> Just Works (tm).
>
> As in the OP, when I have 50 different runnable scripts, it become
> necessary to arrange them in directories. How would you do that in
> your scheme? Currently it looks like they're required to live directly
> above the package containing their code.

I'd say that, if your application contains 50 different runnable scripts  
in several directories, it deserves an install script. Being able to  
execute something from a checked-out copy is fine for a small application  
but in your case I'd say we are off limits...

Python must be able to import the package. In case a) above, this happens  
because the directory containing the script (and the package) is in  
sys.path by default. In case b), because you copy the package into some  
place that is already in sys.path. There is another option: add the  
directory containing the package to sys.path, by setting the environment  
variable PYTHONPATH. Robert Kern already explained how to do that:  
<http://permalink.gmane.org/gmane.comp.python.general/639964>

-- 
Gabriel Genellina




More information about the Python-list mailing list