matplotlib-devel Mailing List for matplotlib

Ted Drain wrote:
> Does this proposal change the way people access this 
> functionality? We have a lot of scripts (and a lot of users with 
> scripts) that use basemap and it tends to be extremely annoying to 
> people when their scripts suddenly break.
>
> Ted
> 
Ted: Unfortunately it would break scripts, but only the initial import.
Instead of
from matplotlib.toolkits.basemap import Basemap
you would do
from mpl_toolkits.basemap.api import Basemap
Everything else would be the same. 
-Jeff
> At 03:34 PM 1/9/2008, Andrew Straw wrote:
> 
>> As the author of the only other known MPL toolkit (at least in the MPL
>> tree), I'm happy with the idea of using a namespace package for
>> mpl_toolkits. I understand your proposal to mean that each toolkit would
>> have a directory structure:
>>
>> setup.py
>> lib/
>> mpl_toolkits/
>> __init__.py (empty)
>> basemap/
>> __init__.py
>> other_files.py
>>
>> This is OK with me, but I question is whether it's necessary to have the
>> "lib" directory -- it seems entirely redundant. I'm fine with either
>> way, though.
>>
>> -Andrew
>>
>> Jeff Whitaker wrote:
>> 
>>> Now that the transforms branch has merged with the trunk, I'd like to
>>> resurrect namespace packages so that toolkits will work again when
>>> matplotlib is installed as an egg. As was discussed in a previous
>>> thread, all __init__.py files in the toolkit hierarchy must be empty
>>> (aside declare_namespace statement). Since lib/matplotlib/__init__.py
>>> contains a lot of important stuff, I think the path of least resistance
>>> is to move the toolkits out of lib/matplotlib and into a separate
>>> directory lib/mpl_toolkits. The semantics of importing a toolkit would
>>> have to change from
>>>
>>> import matplotlib.toolkits.toolkit
>>>
>>> to
>>>
>>> import mpl_toolkit.toolkit.
>>>
>>> Of course, all the toolkit __init__.py files would need to be emptied.
>>> In the case of basemap, this would be changing imports from
>>>
>>> from matplotlib.toolkits.basemap import Basemap
>>>
>>> to something like
>>>
>>> from mpl_toolkits.basemap.api import Basemap
>>>
>>> All the stuff now imported directly into __init__.py would go in api.py.
>>>
>>> I've tried this in my local tree and it seems to work fine. Does this
>>> sound reasonable? If there's general agreement, I can make the
>>> necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
>>>
>>> -Jeff
>>>
>>>
>>> 
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
> Ted Drain Jet Propulsion Laboratory ted...@jp... 
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
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

Does this proposal change the way people access this 
functionality? We have a lot of scripts (and a lot of users with 
scripts) that use basemap and it tends to be extremely annoying to 
people when their scripts suddenly break.
Ted
At 03:34 PM 1/9/2008, Andrew Straw wrote:
>As the author of the only other known MPL toolkit (at least in the MPL
>tree), I'm happy with the idea of using a namespace package for
>mpl_toolkits. I understand your proposal to mean that each toolkit would
>have a directory structure:
>
>setup.py
>lib/
> mpl_toolkits/
> __init__.py (empty)
> basemap/
> __init__.py
> other_files.py
>
>This is OK with me, but I question is whether it's necessary to have the
>"lib" directory -- it seems entirely redundant. I'm fine with either
>way, though.
>
>-Andrew
>
>Jeff Whitaker wrote:
> > Now that the transforms branch has merged with the trunk, I'd like to
> > resurrect namespace packages so that toolkits will work again when
> > matplotlib is installed as an egg. As was discussed in a previous
> > thread, all __init__.py files in the toolkit hierarchy must be empty
> > (aside declare_namespace statement). Since lib/matplotlib/__init__.py
> > contains a lot of important stuff, I think the path of least resistance
> > is to move the toolkits out of lib/matplotlib and into a separate
> > directory lib/mpl_toolkits. The semantics of importing a toolkit would
> > have to change from
> >
> > import matplotlib.toolkits.toolkit
> >
> > to
> >
> > import mpl_toolkit.toolkit.
> >
> > Of course, all the toolkit __init__.py files would need to be emptied.
> > In the case of basemap, this would be changing imports from
> >
> > from matplotlib.toolkits.basemap import Basemap
> >
> > to something like
> >
> > from mpl_toolkits.basemap.api import Basemap
> >
> > All the stuff now imported directly into __init__.py would go in api.py.
> >
> > I've tried this in my local tree and it seems to work fine. Does this
> > sound reasonable? If there's general agreement, I can make the
> > necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
> >
> > -Jeff
> >
> >
>
>
>-------------------------------------------------------------------------
>Check out the new SourceForge.net Marketplace.
>It's the best place to buy or sell services for
>just about anything Open Source.
>http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

As the author of the only other known MPL toolkit (at least in the MPL
tree), I'm happy with the idea of using a namespace package for
mpl_toolkits. I understand your proposal to mean that each toolkit would
have a directory structure:
setup.py
lib/
 mpl_toolkits/
 __init__.py (empty)
 basemap/
 __init__.py
 other_files.py
This is OK with me, but I question is whether it's necessary to have the
"lib" directory -- it seems entirely redundant. I'm fine with either
way, though.
-Andrew 
Jeff Whitaker wrote:
> Now that the transforms branch has merged with the trunk, I'd like to 
> resurrect namespace packages so that toolkits will work again when 
> matplotlib is installed as an egg. As was discussed in a previous 
> thread, all __init__.py files in the toolkit hierarchy must be empty 
> (aside declare_namespace statement). Since lib/matplotlib/__init__.py 
> contains a lot of important stuff, I think the path of least resistance 
> is to move the toolkits out of lib/matplotlib and into a separate 
> directory lib/mpl_toolkits. The semantics of importing a toolkit would 
> have to change from
>
> import matplotlib.toolkits.toolkit
>
> to
>
> import mpl_toolkit.toolkit.
>
> Of course, all the toolkit __init__.py files would need to be emptied. 
> In the case of basemap, this would be changing imports from
>
> from matplotlib.toolkits.basemap import Basemap
>
> to something like
>
> from mpl_toolkits.basemap.api import Basemap
>
> All the stuff now imported directly into __init__.py would go in api.py.
>
> I've tried this in my local tree and it seems to work fine. Does this 
> sound reasonable? If there's general agreement, I can make the 
> necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
>
> -Jeff
>
> 

Thank you, Mike.
On Wednesday 09 January 2008 04:36:21 pm Michael Droettboom wrote:
> I have something that works in r4833. It requires a clean rebuild,
> since the change was only to a header file. It produces no measurable
> slowdown on my fps test. (Of course, Eric's suggestion probably
> wouldn't have either...)
>
> Please let me know how this works for you.
>
> The nice thing about the new implementation is that it is in common
> code, so all backends should support NaNs (whereas before it was only
> Agg, Ps and Pdf). It does, curiously, also work on polygons etc. (the
> NaN-containing vertices are skipped), which doesn't make a whole lot of
> sense, but it's actually harder not to do that. IMHO, if you're putting
> NaNs in polygons you're asking for trouble anyway... If you are, speak
> up now... ;)
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
> > I think this is an oversight on my part when doing the rewrite. The old
> > trunk had special code to deal with NaNs in draw_lines (in some
> > backends, but not all). Since draw_lines disappeared (it was replaced
> > with draw_path), this functionality fell through the cracks. I think
> > somehow bringing the old solution over (without the backend dependence)
> > may be faster than what Eric is proposing, since it is done "on-the-fly"
> > in C (at least for Agg) and doesn't require allocating any more memory
> > for the mask.
> >
> > However, it feels a bit dirty on a gut level to allow two subtly
> > different ways to specify data with gaps. I almost lean toward forcing
> > the user to provide masked arrays if that's what they want to do -- but
> > that's probably not realistic. I think Darren is right -- sometimes
> > NaN's come up when you least expect them, after many other data sets and
> > plots have already worked, and it would be bad for the app to suddenly
> > just fail in that case.
> >
> > I'll look into bringing the old way over to the new code. Failing that,
> > I think Eric's suggestion is quite reasonable.
> >
> > Cheers,
> > Mike
> >
> > Eric Firing wrote:
> >> Darren Dale wrote:
> >>> It looks like the new transforms codebase does not support data that
> >>> contains NaNs the way the old trunk did:
> >>>
> >>> plot([1,2,NaN,4,5]) produces a plot with no line break
> >>> plot([NaN,2,3,4,5]) produces a plot with no line
> >>>
> >>> I know use of NaN's is not encouraged, and we have discussed it on this
> >>> list. But since they are sometimes unintended and unavoidable, I'm
> >>> reporting the behavior so people are not surprised when they get an
> >>> empty plot.
> >>>
> >>> Darren
> >>
> >> This comes up often enough that it might be worth doing automatic
> >> masking of NaNs in the high-level argument processing wherever we are
> >> now doing x=npy.ma.asarray(x) or similar. The calls could be replaced
> >> with x=npy.ma.masked_where(~npy.isfinite(x),x) I have resisted adding
> >> this overhead, but now I think the overhead might be negligible in
> >> almost all cases. It looks like it would be on the order of
> >> milliseconds per high-level call, where by high-level call I mean plot,
> >> pcolor, quiver, etc. (either via pylab or Axes method).
> >>
> >> Eric
> >>
> >> ------------------------------------------------------------------------
> >>- Check out the new SourceForge.net Marketplace.
> >> It's the best place to buy or sell services for
> >> just about anything Open Source.
> >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp
> >>lace _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

I have something that works in r4833. It requires a clean rebuild, 
since the change was only to a header file. It produces no measurable 
slowdown on my fps test. (Of course, Eric's suggestion probably 
wouldn't have either...)
Please let me know how this works for you.
The nice thing about the new implementation is that it is in common 
code, so all backends should support NaNs (whereas before it was only 
Agg, Ps and Pdf). It does, curiously, also work on polygons etc. (the 
NaN-containing vertices are skipped), which doesn't make a whole lot of 
sense, but it's actually harder not to do that. IMHO, if you're putting 
NaNs in polygons you're asking for trouble anyway... If you are, speak 
up now... ;)
Cheers,
Mike
Michael Droettboom wrote:
> I think this is an oversight on my part when doing the rewrite. The old 
> trunk had special code to deal with NaNs in draw_lines (in some 
> backends, but not all). Since draw_lines disappeared (it was replaced 
> with draw_path), this functionality fell through the cracks. I think 
> somehow bringing the old solution over (without the backend dependence) 
> may be faster than what Eric is proposing, since it is done "on-the-fly" 
> in C (at least for Agg) and doesn't require allocating any more memory 
> for the mask.
> 
> However, it feels a bit dirty on a gut level to allow two subtly 
> different ways to specify data with gaps. I almost lean toward forcing 
> the user to provide masked arrays if that's what they want to do -- but 
> that's probably not realistic. I think Darren is right -- sometimes 
> NaN's come up when you least expect them, after many other data sets and 
> plots have already worked, and it would be bad for the app to suddenly 
> just fail in that case.
> 
> I'll look into bringing the old way over to the new code. Failing that, 
> I think Eric's suggestion is quite reasonable.
> 
> Cheers,
> Mike
> 
> Eric Firing wrote:
>> Darren Dale wrote:
>>> It looks like the new transforms codebase does not support data that contains 
>>> NaNs the way the old trunk did:
>>>
>>> plot([1,2,NaN,4,5]) produces a plot with no line break
>>> plot([NaN,2,3,4,5]) produces a plot with no line
>>>
>>> I know use of NaN's is not encouraged, and we have discussed it on this list. 
>>> But since they are sometimes unintended and unavoidable, I'm reporting the 
>>> behavior so people are not surprised when they get an empty plot.
>>>
>>> Darren
>> This comes up often enough that it might be worth doing automatic 
>> masking of NaNs in the high-level argument processing wherever we are 
>> now doing x=npy.ma.asarray(x) or similar. The calls could be replaced 
>> with x=npy.ma.masked_where(~npy.isfinite(x),x) I have resisted adding 
>> this overhead, but now I think the overhead might be negligible in 
>> almost all cases. It looks like it would be on the order of 
>> milliseconds per high-level call, where by high-level call I mean plot, 
>> pcolor, quiver, etc. (either via pylab or Axes method).
>>
>> Eric
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I think this is an oversight on my part when doing the rewrite. The old 
trunk had special code to deal with NaNs in draw_lines (in some 
backends, but not all). Since draw_lines disappeared (it was replaced 
with draw_path), this functionality fell through the cracks. I think 
somehow bringing the old solution over (without the backend dependence) 
may be faster than what Eric is proposing, since it is done "on-the-fly" 
in C (at least for Agg) and doesn't require allocating any more memory 
for the mask.
However, it feels a bit dirty on a gut level to allow two subtly 
different ways to specify data with gaps. I almost lean toward forcing 
the user to provide masked arrays if that's what they want to do -- but 
that's probably not realistic. I think Darren is right -- sometimes 
NaN's come up when you least expect them, after many other data sets and 
plots have already worked, and it would be bad for the app to suddenly 
just fail in that case.
I'll look into bringing the old way over to the new code. Failing that, 
I think Eric's suggestion is quite reasonable.
Cheers,
Mike
Eric Firing wrote:
> Darren Dale wrote:
>> It looks like the new transforms codebase does not support data that contains 
>> NaNs the way the old trunk did:
>>
>> plot([1,2,NaN,4,5]) produces a plot with no line break
>> plot([NaN,2,3,4,5]) produces a plot with no line
>>
>> I know use of NaN's is not encouraged, and we have discussed it on this list. 
>> But since they are sometimes unintended and unavoidable, I'm reporting the 
>> behavior so people are not surprised when they get an empty plot.
>>
>> Darren
> 
> This comes up often enough that it might be worth doing automatic 
> masking of NaNs in the high-level argument processing wherever we are 
> now doing x=npy.ma.asarray(x) or similar. The calls could be replaced 
> with x=npy.ma.masked_where(~npy.isfinite(x),x) I have resisted adding 
> this overhead, but now I think the overhead might be negligible in 
> almost all cases. It looks like it would be on the order of 
> milliseconds per high-level call, where by high-level call I mean plot, 
> pcolor, quiver, etc. (either via pylab or Axes method).
> 
> Eric
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Darren Dale wrote:
> It looks like the new transforms codebase does not support data that contains 
> NaNs the way the old trunk did:
> 
> plot([1,2,NaN,4,5]) produces a plot with no line break
> plot([NaN,2,3,4,5]) produces a plot with no line
> 
> I know use of NaN's is not encouraged, and we have discussed it on this list. 
> But since they are sometimes unintended and unavoidable, I'm reporting the 
> behavior so people are not surprised when they get an empty plot.
> 
> Darren
This comes up often enough that it might be worth doing automatic 
masking of NaNs in the high-level argument processing wherever we are 
now doing x=npy.ma.asarray(x) or similar. The calls could be replaced 
with x=npy.ma.masked_where(~npy.isfinite(x),x) I have resisted adding 
this overhead, but now I think the overhead might be negligible in 
almost all cases. It looks like it would be on the order of 
milliseconds per high-level call, where by high-level call I mean plot, 
pcolor, quiver, etc. (either via pylab or Axes method).
Eric

It looks like the new transforms codebase does not support data that contains 
NaNs the way the old trunk did:
plot([1,2,NaN,4,5]) produces a plot with no line break
plot([NaN,2,3,4,5]) produces a plot with no line
I know use of NaN's is not encouraged, and we have discussed it on this list. 
But since they are sometimes unintended and unavoidable, I'm reporting the 
behavior so people are not surprised when they get an empty plot.
Darren

Michael Droettboom wrote:
> Eric Firing wrote:
>> 2) there is a positioning problem with the table part of table_demo.py.
> 
> I don't see this. (I must just be looking in the wrong place). Can you 
> be more specific?
The problem went away. I was pretty sure I had already deleted my old 
installation and build directory before the previous test, but maybe I 
missed something. With a fresh build and installation it is fine now.
Eric

Nils,
That's weird. I've cleared and rebuilt everything and I still don't see 
this problem on my install. (See my attached copy.)
Thanks for the info. Can you send your versions (Python, numpy etc.) 
and platform info? I don't really know what may be causing this difference.
Cheers,
Mike
Nils Wagner wrote:
> On 2008年1月09日 13:37:35 -0500
> Michael Droettboom <md...@st...> wrote:
>> Eric Firing wrote:
>>> Mike,
>>>
>>> In going through examples (on transforms branch immediately before 
>>> you made the switch), it looks like there are a couple of new bugs
>>> in those included by backend_driver.py:
>>>
>>> 1) legend_demo.py and legend_demo2.py make spurious black blocks, which
>>> go away when the plots are redrawn.
>>
>> This is now fixed in SVN.
>>
>>> 2) there is a positioning problem with the table part of table_demo.py.
>>
>> I don't see this. (I must just be looking in the wrong place). Can 
>> you be more specific?
>>
> Mike,
> 
> Please find attached the output of table_demo.py.
> 
> Cheers,
> 
> Nils
> 
> ------------------------------------------------------------------------
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> Mike,
> 
> In going through examples (on transforms branch immediately before you 
> made the switch), it looks like there are a couple of new bugs
> in those included by backend_driver.py:
> 
> 1) legend_demo.py and legend_demo2.py make spurious black blocks, which
> go away when the plots are redrawn.
This is now fixed in SVN.
> 2) there is a positioning problem with the table part of table_demo.py.
I don't see this. (I must just be looking in the wrong place). Can you 
be more specific?
I also discovered a clipping bug that affects legends. I'm working on 
that now.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Now that the transforms branch has merged with the trunk, I'd like to 
resurrect namespace packages so that toolkits will work again when 
matplotlib is installed as an egg. As was discussed in a previous 
thread, all __init__.py files in the toolkit hierarchy must be empty 
(aside declare_namespace statement). Since lib/matplotlib/__init__.py 
contains a lot of important stuff, I think the path of least resistance 
is to move the toolkits out of lib/matplotlib and into a separate 
directory lib/mpl_toolkits. The semantics of importing a toolkit would 
have to change from
import matplotlib.toolkits.toolkit
to
import mpl_toolkit.toolkit.
Of course, all the toolkit __init__.py files would need to be emptied. 
In the case of basemap, this would be changing imports from
from matplotlib.toolkits.basemap import Basemap
to something like
from mpl_toolkits.basemap.api import Basemap
All the stuff now imported directly into __init__.py would go in api.py.
I've tried this in my local tree and it seems to work fine. Does this 
sound reasonable? If there's general agreement, I can make the 
necessary mods in matplotlib trunk and the mplsizer and basemap toolkits.
-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

Sorry -- I was too thick to get the reference. Maybe if you had 
included a cute picture of a kitten eating a cheeseburger or riding and 
invisible bicycle or something... This list needs more of those ;)
Cheers,
Mike
Tom Holroyd wrote:
> Sorry, I just don't like that word. And the "UR ..." was a lame
> reference to LOL Cats. :-) Sorry, sorry, I'll go away now.
> P.S. I love matplotlib.
> 
> On Tue, 2008年01月08日 at 22:53 +0100, Gael Varoquaux wrote:
>> On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:
>>> I don't think "UR DOIN IT WRONG" is an entirely correct assessment, 
>>> however. Much of this change can be considered refactoring wrt to the 
>>> high-level public API. 
>> Refactoring is often defined (in test driven development) as reworking
>> the codebase given a complete set of tests that pass at the beginning,
>> and should pass at the end.
>>
>> My 2 cents,
>>
>> Gaël
> 
> Dr. Tom
> --
> This precept, however, give I to you, in parting, you fool: Where one
> can no longer love, there should one pass by! Thus spoke Zarathustra.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
I find the usage of linestyle very _unconvenient_, since there are these 
two options - linestyle='--' and linestyle='dashed' - which are not 
exchangable.
I had some code where I initially used the Line2D class, so I had to use 
linestyle='--'. Now I changed my code to use a LineCollection. 
LineCollection doesn't work with linestyle='--', but requires 
linestyle='dashed' - and contrawise Line2D doesn't accept 
linestyle='dashed', but requires linestyle='--'.
Isn't it possible - and desirable - to unify the usage of linestyle ?
Manuel

Sorry, I just don't like that word. And the "UR ..." was a lame
reference to LOL Cats. :-) Sorry, sorry, I'll go away now.
P.S. I love matplotlib.
On Tue, 2008年01月08日 at 22:53 +0100, Gael Varoquaux wrote:
> On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:
> > I don't think "UR DOIN IT WRONG" is an entirely correct assessment, 
> > however. Much of this change can be considered refactoring wrt to the 
> > high-level public API. 
> 
> Refactoring is often defined (in test driven development) as reworking
> the codebase given a complete set of tests that pass at the beginning,
> and should pass at the end.
> 
> My 2 cents,
> 
> Gaël
Dr. Tom
--
This precept, however, give I to you, in parting, you fool: Where one
can no longer love, there should one pass by! Thus spoke Zarathustra.