matplotlib-devel Mailing List for matplotlib

Norbert Nemec wrote:
> Hmm - let me think.... We already have
> rc
> rcParams
> rc_params
> rcdefaults
> rcParamDefaults
> defaultParams
> in the main module of maplotlib
> 
> How about calling the new module 'rcdefaultparams.py', simply to make
> the confusion complete and because I really feel that no other name
> would fit the current "naming scheme" better... ;-)
Yes, it is confusing, there are too many similar names. I suspect some 
are used infrequently enough that we could change them without too much 
pain.
But the new module is really two things: 1) rc utilities (mainly 
validation facilities) and 2) a set of default values. If these are 
kept together the module could be called "rc_init.py" because everything 
is mainly used for rc initialization, although there are things still in 
mpl's __init__.py that are also part of the rc initialization. Or it 
could be called "rc_utils.py" or "rcsetup.py". I would prefer any of 
these to rcdefaultparams.py.
Furthermore, even after factoring out the rc things as you have done the 
mpl namespace is badly cluttered with things like checkdep_dvipng, 
(which is actually part of the rc validation, so maybe it should be in 
your new module) so still more refactoring and/or renaming might be in 
order. I can imagine a class being used to good effect to organize the 
whole business of rc handling.
One more miscellaneous thought: shouldn't mpl.rc() be using the 
validation functions instead of simply stuffing inputs into rcParams?
I suppose this brings us back to the old "traits, properties, or 
neither" question. But incremental improvements such as the one you 
have made are still helpful.
Eric
> 
> Greetings,
> Norbert
> 
> 
> 
> John Hunter wrote:
>> On 6/30/07, Norbert Nemec <Nor...@gm...> wrote:
>> 
>>> Hi there,
>>>
>>> I just checked in some major reorganization work in __init__.py
>>>
>>> The main intention was to move the list of option defaults to a separate
>>> file 'rcdefaults.py' that could be imported from setup.py to access the
>>> settings with minimal dependencies on the remaining code.
>>> 
>> I haven't tested this but I did take a brief look at it and I think
>> your cleaning and organizing is useful. I think we have a naming
>> problem though -- this __init__ module defines an rcdefaults function,
>> which is likely to cause confusion with the new rcdefaults module.
>> Eg,
>>
>> >from matplotlib import rcdefaults
>>
>> will be ambiguous. You may want to consider a new name.
>>
>> DH
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hmm - let me think.... We already have
 rc
 rcParams
 rc_params
 rcdefaults
 rcParamDefaults
 defaultParams
in the main module of maplotlib
How about calling the new module 'rcdefaultparams.py', simply to make
the confusion complete and because I really feel that no other name
would fit the current "naming scheme" better... ;-)
Greetings,
Norbert
John Hunter wrote:
> On 6/30/07, Norbert Nemec <Nor...@gm...> wrote:
> 
>> Hi there,
>>
>> I just checked in some major reorganization work in __init__.py
>>
>> The main intention was to move the list of option defaults to a separate
>> file 'rcdefaults.py' that could be imported from setup.py to access the
>> settings with minimal dependencies on the remaining code.
>> 
>
> I haven't tested this but I did take a brief look at it and I think
> your cleaning and organizing is useful. I think we have a naming
> problem though -- this __init__ module defines an rcdefaults function,
> which is likely to cause confusion with the new rcdefaults module.
> Eg,
>
> >from matplotlib import rcdefaults
>
> will be ambiguous. You may want to consider a new name.
>
> DH
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> 

John Hunter wrote:
> On 6/30/07, Eric Firing <ef...@ha...> wrote:
>> Mike,
>>
>> All this sounds like great progress--thanks! I particularly appreciate
>> the descriptions of what problems you found and how you found them.
>>
>> John et al.: is there a maintainer for each of these backends? I think
> 
> gtk: Steve Chaplin or me
> wx: Ken McIvor
> qt: Darren?
> tk: Charlie?
> 
> After we get these patches in, we can just give Michael commit
> privileges :-) I can probably look at this Monday, but if you want to
> commit and test some of these before then, please do so.
Done. It looks like there is still plenty of memory leakage, but there 
are improvements, and the huge list of uncollectable garbage with tkAgg 
is gone.
I also made memleak_gui.py more flexible with arguments. For example, 
here are tests with three backends, a generous number of loops, and 
suppression of intermediate output:
python ../unit/memleak_gui.py -d wx -s 500 -e 1000 -q
uncollectable list: []
Backend WX, toolbar toolbar2
Averaging over loops 500 to 1000
Memory went from 29316k to 31211k
Average memory consumed per loop: 3.7900k bytes
python ../unit/memleak_gui.py -d tkagg -s 500 -e 1000 -q
uncollectable list: []
Backend TkAgg, toolbar toolbar2
Averaging over loops 500 to 1000
Memory went from 29202k to 31271k
Average memory consumed per loop: 4.1380k bytes
python ../unit/memleak_gui.py -d gtkagg -s 500 -e 1000 -q
uncollectable list: []
Backend GTKAgg, toolbar toolbar2
Averaging over loops 500 to 1000
Memory went from 29324k to 31131k
Average memory consumed per loop: 3.6140k bytes
So, this test is still showing problems, with similar memory consumption 
in these three backends.
Eric
> 
> JDH