[Biopython-dev] GSoC python variant update

Laurent Gautier lgautier at gmail.com
Wed Aug 8 16:37:35 UTC 2012


On 2012-08-08 18:00, biopython-dev-request at lists.open-bio.org wro
> Lenna;
> This all sounds great and will be a nice practical addition to
> Biopython. Thanks for taking it on. Some specific thoughts on your questions:
>
>> >* I'm representing intron locations relative to CDS coords using the
>> >HGVS standards:http://www.hgvs.org/mutnomen/refseq_figure.html
>> >I'd like to know if there are other common ways of representing such
>> >positions.
> I don't know of one myself, so it's great to be following a standard
> rather than reinventing something. Nice work.
>
>> >* In order to customize the display of positions (e.g. 0-based or
>> >1-based), I'm using a class as a configuration container. I've read on
>> >StackOverflow that attempts to use globals or a singleton class are
>> >discouraged in Python, but I have not found practical suggestions for
>> >how to implement module-wide configurations. Suggestions are welcome.

Module-wide configuration can be implemented as variables, as long as 
they are declared before the functions using them.
If considering a package rather than a single module, options can be 
stored in a module dedicated to options (since Python modules are 
singletons).

> With configuration items like this, you have two choices:
>
> - A global variable.
> - Pass the configuration to every function that needs it.
>
> There are tradeoffs with both approaches, but for this case I agree with
> your decision to use globals. Most people will want 0-based/Biopython
> style but it gives those who don't a knob to switch over.

I'd argue that allowing to switch is an invitation to spectacular issues 
down the road.
An easy, yet frightening, example would be the case where using 
third-party code (such a module) changes this without you knowing.

An other scary thought is that this would amount to bringing the 
infamous Perl variable "$[" to Python. Go explain again that folks 
should Python for its elegance and simplicity after that.


Best,

L.



More information about the Biopython-dev mailing list