Michiel de Hoon
mjldehoon at yahoo.com
Sun Mar 8 08:03:31 EDT 2009
--- On Mon, 3/2/09, Peter <biopython at maubp.freeserve.co.uk> wrote:
> I like your suggestion to have a REST XML based module
> under Bio.ExPASy, which means we can deprecate the HTML based
> Bio.Prosite module and in the process make the top level list of
> modules in Biopython a bit shorter. In the long term I think that
> will help people find functionality.
Then, how about the following code organization:
get_prodoc_entry Interface to the get-prodoc-entry CGI script.
get_prosite_entry Interface to the get-prosite-entry CGI script.
get_prosite_raw Interface to the get-prosite-raw CGI script.
get_sprot_raw Interface to the get-sprot-raw CGI script.
sprot_search_ful Interface to the sprot-search-ful CGI script.
sprot_search_de Interface to the sprot-search-de CGI script.
(currently in Bio/ExPASy.py)
Bio/ExPASy/Prosite.py contains read(), parse(), Record for Prosite files
(currently in Bio/Prosite/__init__.py), as well as a Pattern class to handle Prosite patterns (currently in Bio/Prosite/Pattern.py, but this seems to be unused).
Bio/ExPASy/Prodoc.py contains read(), parse(), Record for Prosite documentation files
(currently in Bio/Prosite/Prodoc.py)
Bio/ExPASy/ScanProsite contains scan(), read(), Record to interact with ScanProsite
(currently a broken version to access ScanProsite and parse its results exists in Bio/ExPASy.py and Bio/Prosite/__init__.py).
I have a simplified version of the Prosite and Prodoc parsers. If we use the scheme above, I'll put the new version in Bio/ExPASy/Prosite.py and Bio/ExPASy/Prodoc.py, and deprecate Bio.Prosite.
More information about the Biopython-dev