CFT: fix OfflineIMAP lockup in single-threaded mode

[X Ryl]

I agree with you Nicolas.
For now, I'm not sure anyone reported a bug with due to config object being
changed.
Not even sure it's changed anywhere after being filled.

Yet, the current "config.get" interface is clunky.
You don't know what are the options in which section (without reading all
the code).
Having better organized config object would help documentation first, and
understanding the code then.
I mean:
if (config.general.singlethread)
is better, IMHO, than
if (config.get_option("general", "single_thread") == "True")

For repositories, it could be:
config.repositories["repoNameHere"].nametrans

For making the documentation, one would grep "config\." and have all in the
results, instead of having to understand the variable name and whatever get
passed to the different classes.
What do you think ?

On Mon, Jan 28, 2013 at 9:39 PM, Nicolas Sebrecht <nicolas.s-dev at laposte.net
> wrote:

> On Mon, Jan 28, 2013 at 10:47:22PM +0400, Eygene Ryabinkin wrote:
> > Mon, Jan 28, 2013 at 05:15:53PM +0100, X Ryl wrote:
>
> > > I thought the config was read-only already, and read before any
> > > thread is spawn, so I don't get why it would require a singleton
> > > class ?
> >
> > My current implementation doesn't singleton'ize the 'config', it
> > applies singleton to 'options' that have read/write access.  But, as
> > you can see, 'config' variable from offlineimap/init.py is just a
> > class that holds the configuration items and they can be modified,
> > e.g. by using config.set() method.
> >
> > If we will make, say, 'options' to the global variable, some code can
> > unintentionally modify it and this will be very hard to trace, since
> > any piece of code can do it: variable is global.
>
> How some code would modify the global variable 'options'?
>
> Might be just a matter of opinions but python expects developpers to
> know what they do (e.g. attributes of objects are public). Does safety
> justify the resulting complexity of the code? Not sure.
>
> --
> Nicolas Sebrecht
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/offlineimap-project/attachments/20130128/05ec3e6e/attachment.html>