[Biopython-dev] GSoC python variant update

[Laurent Gautier]

On 2012-08-08 20:44, Lenna Peterson wrote:
> On Wed, Aug 8, 2012 at 12:37 PM, Laurent Gautier <lgautier at gmail.com> wrote:
>> On 2012-08-08 18:00, biopython-dev-request at lists.open-bio.org wro
>>
>>>>> * 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).
>>
> Hi Laurent,
>
> I really like the idea of a configuration module. I will definitely
> move in that direction.
>
>>> 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.
>>
>>
> Yikes. My approach will not be comparable to $[. For starters, it
> wouldn't modify the behavior of every sequence-like object.
>
> My current thought would be to store the 0-based position in an
> attribute `pos`, have a property `pos_str` that returns `pos` +
> `Config.index`. For representations, `__str__` will return `pos_str`,
> and `__repr__` will return `pos` (always 0-based). Math would always
> use the 0-based position.
>
> I intend to keep the influence of the hypothetical mapping Config
> module limited to Biopython Seq* objects. It should also be possible
> to make a kill switch, namely, a version of the Config module where
> all of the settings are neutral to adding (i.e. `def __add__(self,
> other): return other`).

What about making the design decision that string representations that 
are 1-based then, and go beyond making a kill switch by just kill the 
switch ? You'd document it, folks that want 0-based positions would cook 
their own function(s).

I think that configuration modules can be very useful for an application 
(an example here:
http://flask.pocoo.org/snippets/2/ ), but I am more reserved about its 
use in a library.

But do not let me stop you from pursuing this; I am only expressing an 
opinion. One last point though.
Let me describe a possible scenario:

3rd-party module "foo" is using the Biopython Seq* part, and its author 
thinks that Config.index should at 1 one, so he/she sets it accordingly.
An early line in foo.py is:
from somewhere.in.biopython.seq import config
config.index = 1

There is an other piece of code (let's call it bar.py), written by 
someone else or by the same person at a different time. Now the hype is 
all about 0-based indexes, so the author sets it to be sure:
from somewhere.in.biopython.seq import config
config.index = 0

To complete the scenario bar.py is using foo.py, or the other way 
around. The requirement for one an other does not even have to be 
direct. Now config.index will be what the last piece of code sets it to, 
although other parts of the code might assume it is set to something else.

That sort of situation is not prevented from happening with any sort of 
module in Python (e.g., import sys; sys.stdout = sys.stderr), but people 
know they should not do it. Here the config.index would appear as 
something people should change if they like.

Again, that's just an opinion. Others might differ.

Best,


Laurent

>
> Please let me know if this would not fully address your concerns.
>
> Cheers,
>
> Lenna