matplotlib-devel Mailing List for matplotlib

Tom Holroyd (NIH/NIMH) [E] wrote:
> More info on the memory leaks. It has to do with GtkToolbar.insert(). 
> For example, in the function _init_toolbar2_4() in backend_gtk.py, 
> commenting out any of the self.insert() calls will change how much it 
> leaks. Comment them all out, plus the self.fileselect assignment (which 
> is very slow, by the way, and accounts for more leaks than other places) 
> and it'll leak minimally.
> 
> Does that mean this is a bug in gtk?
> 
I don't know. I have been experimenting with a simple pure pygtk demo 
(no mpl components). I was about to conclude that it leaked whenever 
the toplevel show() method was used, but I just now did another test 
that suggests this is not the case if the mainloop in started and the 
window is killed each time--which would be the normal mode of operation, 
but is tedious to test for large numbers of iterations. (It should be 
possible to simulate it instead.) I have not tried enough of such loops 
to be sure yet, but overall, I am suspecting that the problem in mpl is 
not inevitable but has to do with the way the gtk things are called and 
referenced. I think we have a similar problem with all interactive 
backends (the only one I didn't test is Qt4Agg) which also makes me 
suspect we are violating some gui rule, rather than that gtk, qt3, wx, 
and tk all have leaks.
I added a MemoryMonitor class to cbook.py to make this testing a little 
easier. No docstrings yet, but it will be obvious what it does.
Eric

More info on the memory leaks. It has to do with GtkToolbar.insert(). For example, in the function _init_toolbar2_4() in backend_gtk.py, commenting out any of the self.insert() calls will change how much it leaks. Comment them all out, plus the self.fileselect assignment (which is very slow, by the way, and accounts for more leaks than other places) and it'll leak minimally.
Does that mean this is a bug in gtk?
-- 
Tom Holroyd, Ph.D.
We experience the world not as it is, but as we expect it to be.

On 3/30/07, Darren Dale <dd...@co...> wrote:
> This is fixed in svn 3137.
Many, many thanks Darren, especially for looking into this so quickly.
I'll finish testing this setup with the rest of our codes and will let
you know if we hit any other Qt-specific bumps.
Cheers,
f

On Friday 30 March 2007 06:07:26 am Darren Dale wrote:
> On Friday 30 March 2007 1:37:09 am Fernando Perez wrote:
> > Hi all,
> >
> > I'm wondering if anyone knows what the problem is (traceback at the
> > end). If I use close() when running with the Qt4Agg backend under
> > OSX, the figures do not close, and I get a nasty traceback instead.
> > Perhaps the problem also exists on other OSes (I hope, so it's easier
> > to fix), but I only have a Qt4 build on OSX (PPC) 10.4.9.
> >
> > This is with a fairly recent SVN build:
> >
> > In [21]: matplotlib.__revision__
> > Out[21]: '$Revision: 3125 $'
> >
> > Any help on this one would be greatly appreciated (and John: I think
> > this is the backend we'll be using, so it would be very nice to get
> > this fixed :)
This is fixed in svn 3137.
Darren

On Friday 30 March 2007 1:37:09 am Fernando Perez wrote:
> Hi all,
>
> I'm wondering if anyone knows what the problem is (traceback at the
> end). If I use close() when running with the Qt4Agg backend under
> OSX, the figures do not close, and I get a nasty traceback instead.
> Perhaps the problem also exists on other OSes (I hope, so it's easier
> to fix), but I only have a Qt4 build on OSX (PPC) 10.4.9.
>
> This is with a fairly recent SVN build:
>
> In [21]: matplotlib.__revision__
> Out[21]: '$Revision: 3125 $'
>
> Any help on this one would be greatly appreciated (and John: I think
> this is the backend we'll be using, so it would be very nice to get
> this fixed :)
Hi Fernando,
I'll have a look at this, but I might not be able to get to it until this 
weekend. Is that ok for you?
Darren

Hi all,
I'm wondering if anyone knows what the problem is (traceback at the
end). If I use close() when running with the Qt4Agg backend under
OSX, the figures do not close, and I get a nasty traceback instead.
Perhaps the problem also exists on other OSes (I hope, so it's easier
to fix), but I only have a Qt4 build on OSX (PPC) 10.4.9.
This is with a fairly recent SVN build:
In [21]: matplotlib.__revision__
Out[21]: '$Revision: 3125 $'
Any help on this one would be greatly appreciated (and John: I think
this is the backend we'll be using, so it would be very nice to get
this fixed :)
Cheers,
f
In [19]: close('all')
---------------------------------------------------------------------------
<type 'exceptions.TypeError'> Traceback (most recent call last)
/Users/fperez/py4science/examples/<ipython console> in <module>()
/usr/local/txpython/local/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/pylab.py
in close(*args)
 728 if arg=='all':
 729 for manager in _pylab_helpers.Gcf.get_all_fig_managers():
--> 730 _pylab_helpers.Gcf.destroy(manager.num)
 731 elif isinstance(arg, int):
 732 _pylab_helpers.Gcf.destroy(arg)
/usr/local/txpython/local/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py
in destroy(num)
 26 del Gcf.figs[num]
 27 #print len(Gcf.figs.keys()), len(Gcf._activeQue)
---> 28 figManager.destroy()
 29 gc.collect()
 30
/usr/local/txpython/local/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/backends/backend_qt4.py
in destroy(self, *args)
 246 self.window._destroying = True
 247 if DEBUG: print "destroy figure manager"
--> 248 self.window.close(True)
 249
 250 class NavigationToolbar2QT( NavigationToolbar2, QtGui.QWidget ):
<type 'exceptions.TypeError'>: too many arguments to QWidget.close(),
0 at most expected

Travis and others,
In the course of trying to understand memory leaks in matplotlib I have 
been trying to understand a bit about the garbage collector. If I 
understand correctly, any container that can can hold references to 
other containers could lead to a reference cycle; if the container 
supports the gc mechanism, then the gc can at least find the cycles. If 
the containers do not have __del__ methods, then the gc can also break 
the cycles and reclaim the memory. (This also seems to imply that 
__del__ methods should be avoided if at all possible, and I don't 
understand the implications and applications of this.)
I notice that numpy.ndarray does not support the gc, correct? And since 
an ndarray can hold other containers, it could lead to uncollectable 
cycles, correct?
Did you decide not to include gc support because it is not actually 
needed or useful? If so, what am I missing?
I don't think the lack of gc support in numpy has anything to do with 
the present leak problem in mpl, so I am asking about numpy partly out 
of curiosity, and partly in the hope that your answer will help me 
understand exactly when one really needs to worry about gc support in 
extension code--mpl has quite a bit of extension code, and relies on 
much outside extension code as well. The one little bit of extension 
code I wrote for numpy, the wrapper part of the contour routine, does 
not support the gc--and if this is a mistake, I want to know about it. 
(I am beginning to suspect that it should support the gc, although it is 
not part of our most basic problem at the moment.)
Googling has not turned up much information beyond the standard python 
docs about the gc, extension code, and memory leaks in python.
Thanks for whatever insight and advice you can provide.
Eric

In fact, the following loop leaks:
for i in range(indEnd):
 fig = pylab.figure()
about 2k per on my box _even_ with toolbar set to None.
With it set to toolbar2, it is very noticably slower, and leaks 120k per.
-- 
Tom Holroyd, Ph.D.
We experience the world not as it is, but as we expect it to be.

Tom Holroyd (NIH/NIMH) [E] wrote:
>> import os,matplotlib
>> matplotlib.use('Agg')
>> from matplotlib.figure import Figure
>> from matplotlib.cbook import report_memory
>>
>> def plot():
>> fig = Figure()
>> i = 0
>> while True:
>> print report_memory(i)
>> fig.clf()
>> ax = fig.add_axes([0.1,0.1,0.7,0.7])
>> ax.plot([1,2,3])
>> i += 1
>>
>> if __name__ == '__main__': plot()
>
> I have matplotlib-0.90.0 installed, and this script doesn't leak for 
> me. It grows a bit as shown in the graph, then stabilizes. I'm on FC4 
> with Python 2.4.3.
>
> ------------------------------------------------------------------------
>
Right - here too (on macos x), it levels off about about 15 times the 
initial memory usage. I just didn't run it long enough to notice that 
before.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

You used gnuplot to plot MPL memory use?
for shame, for shame!
;-)
-Chris
Tom Holroyd (NIH/NIMH) [E] wrote:
> as shown in the graph, then stabilizes.
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

> import os,matplotlib
> matplotlib.use('Agg')
> from matplotlib.figure import Figure
> from matplotlib.cbook import report_memory
> 
> def plot():
> fig = Figure()
> i = 0
> while True:
> print report_memory(i)
> fig.clf()
> ax = fig.add_axes([0.1,0.1,0.7,0.7])
> ax.plot([1,2,3])
> i += 1
> 
> if __name__ == '__main__': plot()
I have matplotlib-0.90.0 installed, and this script doesn't leak for me. It grows a bit as shown in the graph, then stabilizes. I'm on FC4 with Python 2.4.3.
-- 
Tom Holroyd, Ph.D.
We experience the world not as it is, but as we expect it to be.

John Hunter wrote:
> On 3/28/07, Jeff Whitaker <js...@fa...> wrote:
>
>> John: I just added macos x support in the report_memory function.
>> Regarding Eric's memory leak #2 (which occurs even for non-gui
>> backends), here's a simple script to trigger it:
>>
>
> Thanks Jeff, could you add this to the unit dir as well?
>
> JDH
Done - added as memleak_nongui.py
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On 3/28/07, Jeff Whitaker <js...@fa...> wrote:
> John: I just added macos x support in the report_memory function.
> Regarding Eric's memory leak #2 (which occurs even for non-gui
> backends), here's a simple script to trigger it:
>
Thanks Jeff, could you add this to the unit dir as well?
JDH

John Hunter wrote:
> On 3/27/07, Eric Firing <ef...@ha...> wrote:
> 
>> I can add a couple of things to item (1) below. First, the problem
>> occurs only with toolbar2, not with classic or None. Second, a script
>> that illustrates it is attached.
>> 
>
> I defintely agree that this is important -- and it is a big help to
> have a script and the info that you narrowed the problem down to the
> presence of the toolbar. report_memory is platform dependent since ps
> is. I added a report_memory function to cbook so we could have some
> common functionality to rely on. So far it checks for linux or sunos5
> and we should add to this and fix it up as necessary. I also stripped
> the script down to the bare essentials (the memory report) and added
> it to unit/memleak_gui.py so others can use it for testing.
>
> It turns out if you add a savefig call, TkAgg is terribly (1MB per
> figure) and I can reproduce the smaller toolbar induced leak on my
> platform with TkAgg and GTKAgg. I tried adding some code to
> figure.clf to help, but it didn't. I also spent some time trying to
> figure out what was going wrong with TkAgg but unfortunately did not
> succeed. I don't know anything about Tk, really. One interesting
> thing: the enormous filesave leak in TkAgg also only occurs if the
> toolbar is present. w/o the toolbar, neither gtkagg nor tkagg leak w/
> or w/o the filesave. With the toolbar, both leak a 20-80k w/o the
> file save.
>
> Developers: if you know something about a particular GUI, try this
> script with -dYourGUIBackend and see if you can isolate the problem!
>
> JDH
>
> # in svn as unit/memleak_gui.py
>
> #!/usr/bin/env python
> '''
> This illustrates a leak that occurs with any interactive backend.
> Run with
>
> > python memleak_gui.py -dGTKAgg # or TkAgg, etc..
>
> You may need to edit cbook.report_memory to support your platform
>
> '''
> import os, sys, time
> import gc
> import matplotlib
>
> #matplotlib.use('TkAgg') # or TkAgg or WxAgg or QtAgg or Gtk
> matplotlib.rcParams['toolbar'] = 'toolbar2' # None, classic, toolbar2
> #matplotlib.rcParams['toolbar'] = None # None, classic, toolbar2
>
> import pylab
> from matplotlib import _pylab_helpers as ph
> import matplotlib.cbook as cbook
>
> indStart, indEnd = 30, 50
> for i in range(indEnd):
>
> fig = pylab.figure()
> fig.savefig('test')
> fig.clf()
> pylab.close(fig)
> val = cbook.report_memory(i)
> print i, val
> gc.collect()
> if i==indStart: start = val # wait a few cycles for memory usage
> to stabilize
>
> gc.collect()
> print
> print 'uncollectable list:', gc.garbage
> print
> end = val
> if i > indStart:
> print 'Average memory consumed per loop: %1.4fk bytes\n' %
> ((end-start)/float(indEnd-indStart))
> 
John: I just added macos x support in the report_memory function. 
Regarding Eric's memory leak #2 (which occurs even for non-gui 
backends), here's a simple script to trigger it:
import os,matplotlib
matplotlib.use('Agg')
from matplotlib.figure import Figure
from matplotlib.cbook import report_memory
def plot():
 fig = Figure()
 i = 0
 while True:
 print report_memory(i)
 fig.clf()
 ax = fig.add_axes([0.1,0.1,0.7,0.7])
 ax.plot([1,2,3])
 i += 1
if __name__ == '__main__': plot()
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On 3/27/07, Eric Firing <ef...@ha...> wrote:
> I can add a couple of things to item (1) below. First, the problem
> occurs only with toolbar2, not with classic or None. Second, a script
> that illustrates it is attached.
I defintely agree that this is important -- and it is a big help to
have a script and the info that you narrowed the problem down to the
presence of the toolbar. report_memory is platform dependent since ps
is. I added a report_memory function to cbook so we could have some
common functionality to rely on. So far it checks for linux or sunos5
and we should add to this and fix it up as necessary. I also stripped
the script down to the bare essentials (the memory report) and added
it to unit/memleak_gui.py so others can use it for testing.
It turns out if you add a savefig call, TkAgg is terribly (1MB per
figure) and I can reproduce the smaller toolbar induced leak on my
platform with TkAgg and GTKAgg. I tried adding some code to
figure.clf to help, but it didn't. I also spent some time trying to
figure out what was going wrong with TkAgg but unfortunately did not
succeed. I don't know anything about Tk, really. One interesting
thing: the enormous filesave leak in TkAgg also only occurs if the
toolbar is present. w/o the toolbar, neither gtkagg nor tkagg leak w/
or w/o the filesave. With the toolbar, both leak a 20-80k w/o the
file save.
Developers: if you know something about a particular GUI, try this
script with -dYourGUIBackend and see if you can isolate the problem!
JDH
# in svn as unit/memleak_gui.py
#!/usr/bin/env python
'''
This illustrates a leak that occurs with any interactive backend.
Run with
 > python memleak_gui.py -dGTKAgg # or TkAgg, etc..
You may need to edit cbook.report_memory to support your platform
'''
import os, sys, time
import gc
import matplotlib
#matplotlib.use('TkAgg') # or TkAgg or WxAgg or QtAgg or Gtk
matplotlib.rcParams['toolbar'] = 'toolbar2' # None, classic, toolbar2
#matplotlib.rcParams['toolbar'] = None # None, classic, toolbar2
import pylab
from matplotlib import _pylab_helpers as ph
import matplotlib.cbook as cbook
indStart, indEnd = 30, 50
for i in range(indEnd):
 fig = pylab.figure()
 fig.savefig('test')
 fig.clf()
 pylab.close(fig)
 val = cbook.report_memory(i)
 print i, val
 gc.collect()
 if i==indStart: start = val # wait a few cycles for memory usage
to stabilize
gc.collect()
print
print 'uncollectable list:', gc.garbage
print
end = val
if i > indStart:
 print 'Average memory consumed per loop: %1.4fk bytes\n' %
((end-start)/float(indEnd-indStart))

I can add a couple of things to item (1) below. First, the problem 
occurs only with toolbar2, not with classic or None. Second, a script 
that illustrates it is attached.
Eric
Eric Firing wrote:
> In 2007, two different major memory leaks have been identified:
> 
> 1) Eric Pellegrini showed that a loop over figure(); close() leaks. I 
> have verified that this occurs with any interactive backend, but not 
> with non-interactive backends. This may be the same problem that was 
> reported in other messages, such as one by Dylan Passmore in January.
> 
> 2) There is a recent thread "Re: Memory leak in basemap or matplotlib" 
> showing that even with a non-interactive backend, a seemingly-pointless 
> call to cla() is needed to prevent a leak.
> 
> I would like to suggest that we try harder to solve these problems ASAP. 
> This kind of malfunctioning at the core of mpl worries me.
> 
> I have spent quite a bit of time trying to figure out (1), and I have 
> tracked it down to the NavigationToolbar2. Eliminate the toolbar by 
> putting None in the rc slot, and the memory leak vanishes. It looks to 
> me like some explicit call to a destroy method may be needed to 
> dismantle the toolbar when a figure is closed and/or deleted. I suspect 
> that each gui toolkit is keeping references to components, and the 
> toolbar is not getting the word when the window is destroyed. 
> gc.garbage verifies that the toolbar components are what get left behind.
> 
> So, I hope a gui toolkit backend wizard can step forward and say, "Of 
> course, we just need to put a __del__ method here with a call to 
> destroy()", or something like that.
> 
> I have spent much less time on (2), and made no progress.
> 
> We are relying very heavily on the gc--mpl has cyclic references all 
> over the place. Is anyone sure that we don't need explicit gc support 
> in any of the extension code? Can *everything* in the extension code be 
> handled correctly with reference counting? Is this independent of how 
> things defined in extension code are used at the python level?
> 
> It is not clear to me that gc debugging methods even allow one to see 
> problems in extension code that do not have some degree of gc support. 
> The standard documentation of the gc module and the gc C API is minimal.
> 
> Eric
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

In 2007, two different major memory leaks have been identified:
1) Eric Pellegrini showed that a loop over figure(); close() leaks. I 
have verified that this occurs with any interactive backend, but not 
with non-interactive backends. This may be the same problem that was 
reported in other messages, such as one by Dylan Passmore in January.
2) There is a recent thread "Re: Memory leak in basemap or matplotlib" 
showing that even with a non-interactive backend, a seemingly-pointless 
call to cla() is needed to prevent a leak.
I would like to suggest that we try harder to solve these problems ASAP. 
 This kind of malfunctioning at the core of mpl worries me.
I have spent quite a bit of time trying to figure out (1), and I have 
tracked it down to the NavigationToolbar2. Eliminate the toolbar by 
putting None in the rc slot, and the memory leak vanishes. It looks to 
me like some explicit call to a destroy method may be needed to 
dismantle the toolbar when a figure is closed and/or deleted. I suspect 
that each gui toolkit is keeping references to components, and the 
toolbar is not getting the word when the window is destroyed. 
gc.garbage verifies that the toolbar components are what get left behind.
So, I hope a gui toolkit backend wizard can step forward and say, "Of 
course, we just need to put a __del__ method here with a call to 
destroy()", or something like that.
I have spent much less time on (2), and made no progress.
We are relying very heavily on the gc--mpl has cyclic references all 
over the place. Is anyone sure that we don't need explicit gc support 
in any of the extension code? Can *everything* in the extension code be 
handled correctly with reference counting? Is this independent of how 
things defined in extension code are used at the python level?
It is not clear to me that gc debugging methods even allow one to see 
problems in extension code that do not have some degree of gc support. 
The standard documentation of the gc module and the gc C API is minimal.
Eric

I've got a routine, attached, which is simple and fast, and returns very nicely spaced ticks along with the number of minor ticks. It's an old algorithm from a '73 ACM article, but tried and true. I suppose this should be implemented as a Locator, but I'm not very familiar with the pylab code. Perhaps someone could demonstrate the appropriate way?
-- 
Tom Holroyd, Ph.D.
We experience the world not as it is, but as we expect it to be.

On 3/26/07, Eric Firing <ef...@ha...> wrote:
> Popping the 'a' entry inside the function did not affect the dictionary
> that was passed in; it evidently gets copied automatically.
>
> Am I missing something? Or should I go ahead and strip out the extra
> copies and modify the corresponding advice in CODING_GUIDE?
Well, that was certainly a surprise to me -- yep all the copying of
**kwargs can be eliminated and the CODING_GUIDE updated. Thanks for
discovering this and pointing it out!
JDH

Those of you who updated from mpl svn between last night and now, may
have noticed that the pan/zoom/etc functionality was broken. Last
night I factored out the callback event handler that we use to support
the toolbar navigation into a reusable class in cbook. And I broke
it.
It is now fixed in revision 3126. If you want to use something like
this in your own code, it goes like so
In [1]: from matplotlib.cbook import CallbackRegistry
In [2]: signals = 'eat', 'drink', 'be merry'
In [3]: def oneat(x): print 'eat', x
In [5]: def ondrink(x): print 'drink', x
In [6]: callbacks = CallbackRegistry(signals)
In [7]: cid = callbacks.connect('eat', oneat)
In [8]: cid2 = callbacks.connect('drink', ondrink)
In [11]: callbacks.process('drink', 123)
drink 123
In [12]: callbacks.process('eat', 456)
eat 456
In [13]: callbacks.process('be merry', 456)
In [14]: callbacks.disconnect(cid)
In [15]: callbacks.process('eat', 456)
In [16]: tmp = callbacks.connect('drunk', ondrink)
------------------------------------------------------------
Traceback (most recent call last):
 File "<ipython console>", line 1, in ?
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/cbook.py",
line 39, in connect
 self._check_signal(s)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/cbook.py",
line 32, in _check_signal
 raise ValueError('Unknown signal "%s"; valid signals are %s'%(s, signals))
ValueError: Unknown signal "drunk"; valid signals are ['be merry',
'drink', 'eat']
JDH

The coding guide recommends that any **kwargs dictionary that is passed 
into a function should be copied so that the original is unaffected when 
items are popped off inside the function. I noticed that this is not 
done by pylab functions generated by boilerplate.py, and in fact I don't 
think it is necessary:
In [9]:def test2(**kw):
 ...: first = kw.pop('a')
 ...: print first
 ...: print kw
 ...:
 ...:
In [10]:test2(**kw)
c
{'b': 'd'}
In [11]:kw
Out[11]:{'a': 'c', 'b': 'd'}
Popping the 'a' entry inside the function did not affect the dictionary 
that was passed in; it evidently gets copied automatically.
Am I missing something? Or should I go ahead and strip out the extra 
copies and modify the corresponding advice in CODING_GUIDE?
Eric

"Edin Salkovic" <edi...@gm...> writes:
> I would just suggest using open() instead of file(), but this is a
> general Python tip :)
>
> Everything else seems OK.
Thanks, committed.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 3/21/07, John Hunter <jd...@gm...> wrote:
> On 3/21/07, Fernando Perez <fpe...@gm...> wrote:
>
> > And yes, properties are actually OK even with 2.2, so there's no
> > reason to avoid them (and they do provide a nicer, claner user API).
> > Decorators are 2.4-only though.
>
> I'm not opposed to properties in principle -- I just didn't want to
> start incorporating them by happenstance. We have the long running
> unresolved issue of whether to use traits or properties, so I scrubbed
> the properties as a foolish consitency, to stick to one design
> approach until we have made a formal decision on how we want to
> approach this, and then port mpl properties en masse.
I wasn't really voting for properties or traits, that decision is
ultimately your call. They both provide similar user-visible benefits
(traits having more open-ended possibilities, of course).
> But I think it would be a good idea to go ahead and derive Artist from
> object to make sure this doesn't cause any troubles, and likewise for
> the other top level classes, eg FigureCanvasBase and friends.
Yes. I fail to understand why the python VM doesn't raise an
exception of some kind when property() is called on an old-style
class. It won't work anyway, so why the hell does it fail silently???
 I'm sure Eric and I are not the only people to have wasted time on
that particular trap.
Cheers,
f

On 3/21/07, Fernando Perez <fpe...@gm...> wrote:
> And yes, properties are actually OK even with 2.2, so there's no
> reason to avoid them (and they do provide a nicer, claner user API).
> Decorators are 2.4-only though.
I'm not opposed to properties in principle -- I just didn't want to
start incorporating them by happenstance. We have the long running
unresolved issue of whether to use traits or properties, so I scrubbed
the properties as a foolish consitency, to stick to one design
approach until we have made a formal decision on how we want to
approach this, and then port mpl properties en masse.
But I think it would be a good idea to go ahead and derive Artist from
object to make sure this doesn't cause any troubles, and likewise for
the other top level classes, eg FigureCanvasBase and friends.
JDH

Fernando Perez wrote:
> On 3/21/07, Eric Firing <ef...@ha...> wrote:
> 
>> Properties would be OK for 2.3; I was thinking we might want to use
>> them. When a getter and setter already exist, all it takes is the one
>> extra line of code, plus a suitable (unused) name for the property. I
>> decided not to pursue traits (if at all) until we can use the Enthought
>> package as-is. But I think that properties could be converted to traits
>> very easily if we wanted to do that in the future, so starting with
>> properties would not be wasted effort. This is getting a bit off-topic,
>> though.
> 
> Minor note: if you are going to use properties, make sure all classes
> using them are new-style (inherit from object). With old-style
> classes, properties fail in silent and mysterious ways that may lead
> to much head-scratching.
Not minor at all--I ran into exactly this problem a few months ago with 
my first foray into properties, and it did indeed take quite a bit of 
head-scratching before I realized the problem. And I am embarrassed to 
say that I had forgotten about it until your reminder above.
Thanks.
Eric