matplotlib-devel Mailing List for matplotlib (Page 2)

On Tue, Sep 23, 2008 at 3:22 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Hello,
>
> I'm working on the fancy annotation thing I mentioned the other day,
> and I want to have some feedback and advice.
>
> As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
> the annotation will be consist of a fancy box + fancy arrow. And my
> current plan is to put the fancy arrow things as an arrow patch class
> in the patches.py. The new class would be very similar to the
> FancyBboxPatch class. It will take three control points of quadratic
> bezier path as an input, and will draw an arrow around this path (an
> example is attached). For example
>
> mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)],
> arrowstyle="simple",
> ec="blue!50!white",
> fc="blue!20!white")
>
> But, patches.py already has three arrow classes.
>
> * Arrow(x, y, dx, dy)
> * FancyArrow(x, y, dx, dy)
> * YAArrow(figure, xytip, xybase)
>
> And I'm a bit hesitating in adding yet another arrow class. One way
> I'm considering is to merge my arrow class with the currently existing
> FancyArrow class (or other). But their interface is a bit different
> and I'm afraid that it may confuse users. So, how others think? Would
> it better to simply have a seperate arrow class or to have it merged
> into one of the existing arrow classes?
Well merging is obviously better. I wrote YAArrow to support
plain-vanilla annotations. AFAIK, they are used nowhere else, so as
long as we could come up with one arrow class that works with
plain-vanilla and fancy annotations, that would be good. But it may
be easier said than done. These annotation arrows are really helper
classes that are instantiated by higher level functions (eg users most
likely won't be creating them themselves) and since they all have the
basic patch interface, I don't think having a proliferation of them is
the worst thing in the world, though the ideal is to have as few
classes as possible that serve as many cases as possible.
> The other thing is, as I said, the annotation is consist of a fancy
> box and fancy arrow, which means we need to draw a union of two closed
> bezier path. I hoped that the agg package have those kind
> functionality but I couldn't find one (if there is, please let me
> know). So, I think there are two options.
I believe you are looking for the scanline boolean algebra -- search
the antigrain demo page
 http://www.antigrain.com/demo/index.html
for scanline_boolean.cpp. Of course, we would need to support the
other major backends too....
> * Forget the union operation and fake it by modifying the order of
> "stroke" and "fill", i.e, stroke the paths of the box and arrow first
> then fill each path later (with a same color). The above figure uses
> this approach. It would not work if your want a transparent fill
> color.
>
> * Or, use an external library.
> 2geom(http://lib2geom.sourceforge.net/) seems promising, and I
> currently have a simple wrapper based on it which does the job (2geom
> does provide a python interface but not all of its funtionality are
> wrapped yet. So I needed make a few changes).
This appears to be LGPL, so we will not be using it in the main distro.

Hello,
I'm working on the fancy annotation thing I mentioned the other day,
and I want to have some feedback and advice.
As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
the annotation will be consist of a fancy box + fancy arrow. And my
current plan is to put the fancy arrow things as an arrow patch class
in the patches.py. The new class would be very similar to the
FancyBboxPatch class. It will take three control points of quadratic
bezier path as an input, and will draw an arrow around this path (an
example is attached). For example
 mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)],
 arrowstyle="simple",
 ec="blue!50!white",
 fc="blue!20!white")
But, patches.py already has three arrow classes.
 * Arrow(x, y, dx, dy)
 * FancyArrow(x, y, dx, dy)
 * YAArrow(figure, xytip, xybase)
And I'm a bit hesitating in adding yet another arrow class. One way
I'm considering is to merge my arrow class with the currently existing
FancyArrow class (or other). But their interface is a bit different
and I'm afraid that it may confuse users. So, how others think? Would
it better to simply have a seperate arrow class or to have it merged
into one of the existing arrow classes?
The other thing is, as I said, the annotation is consist of a fancy
box and fancy arrow, which means we need to draw a union of two closed
bezier path. I hoped that the agg package have those kind
functionality but I couldn't find one (if there is, please let me
know). So, I think there are two options.
 * Forget the union operation and fake it by modifying the order of
"stroke" and "fill", i.e, stroke the paths of the box and arrow first
then fill each path later (with a same color). The above figure uses
this approach. It would not work if your want a transparent fill
color.
 * Or, use an external library.
2geom(http://lib2geom.sourceforge.net/) seems promising, and I
currently have a simple wrapper based on it which does the job (2geom
does provide a python interface but not all of its funtionality are
wrapped yet. So I needed make a few changes).
My inclination is to go with the first option. But since this seems a
bit hackish way to do it, I want to know how others think.
Any comment, suggestion, or advice would be appreciated.
-JJ

On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote:
> Attached is a diff against revision 6115 that contains a patch to
> improve the behavior of the legend function when showing legends for
Erik,
I haven't had a chance to get to this yet. Could you please also post
it on the sf patch tracker so it doesn't get dropped, and ping us with
a reminder in a few days if nothing has happened....
JDH

Hi.
I don't think my last message (sent a few days ago) made it to the
mailing list. I'm reposting it again.
On Fri, Sep 19, 2008 at 4:50 PM, Jae-Joon Lee <lee...@gm...> wrote:
> I just uploaded a slightly modified patch with more doumentations.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=2119751&group_id=80706&atid=560722
>
> I added a documentation for the colors.py module and
> ColorConverter.to_rgb() method. Is there any other place I need to
> care?
> I'll see what I can do with the user's guide also.
>
> Jouni,
> Thanks for the suggestion. But I'm afraid that I'm not so keen about
> implementing your suggestions, although their implementation should be
> very straight forward. My intention was to support only a simple color
> mixing, so trivial that my brain can actually predict the result.
> While my current code understands strings like
> "orange!30!purple!50!white", I don't think I'll ever use it because it
> is hard to predict the resulting color (at least for me). Instead,
> I'll just to look up the color table and pick up the color I want. So,
> I'm sorry, but I may not implement those features you suggested unless
> you or someone else give me a good motivation. On the other hand, I
> added a "mix_rgb" method in the ColorConverter class, which partially
> support what you have suggested.
>
> Regards,
>
> -JJ
I also tried to take a look at the user's guide documentation, but I
couldn't find the relevant section about the color (under the
doc/users directory) while the pdf version linked in the homepage DO
have a section about the color. Is it that the new sphinx-based docs
does not have the color section yet? or am I looking at the wrong
directories?
Regards,
-JJ

On Tue, Sep 16, 2008 at 3:26 AM, David M. Kaplan <Dav...@ir...> wrote:
> Hi,
>
> I would just undo what I have done rather than putting a lot of moved
> messages all over the place. I personally find the mix of matlab and
> non-matlab stuff in mlab confusing, but I will go with the group
> consensus.
Since noone else had anything to add here, I moved all the
numerical_methods methods back into mlab until we have a more
comprehensive solution that is friendly to the existing codebase (one
of my apps was just bitten by it...)
JDH

Attached is a diff against revision 6115 that contains a patch to
improve the behavior of the legend function when showing legends for
Collections (e.g. pyplot.scatter plots). The implemented behavior
shows three sample scatter points, adapting the properties and showing
three different colors or sizes in the even that either vary across
the points.
However, this patch is not entirely correct - I've attached a testing
script and an example of the output - as you can see, with a number of
scatter plots, the alignment between the scatter symbols and the text
is off in the legend. I suspect this has to do with the
get_window_extent(self,render) function I had to add to the Collection
class... I'm really not entirely sure what that function is supposed
to do (or what coordinates it's supposed to be transformed into). Can
anyone provide some guidance as to what should be done to fix this
vertical offset problem?

Conrad B Ammon wrote:
> 
> I can't figure out sourceforge's interface to submit a ticket, so I'm 
> mailing this to the devel list. That'll give you a sense of my urgency 
> ;- )
> 
> Subject: Axes Ylims are reversed
> Version: 0.98.3
> 
> when calling get_xlims(), the values returned are in increasing order: 
> [xmin, xmax]. With get_ylims() however, it is reversed.
> # make axes in figure, named ax
> 
> ax.get_xlims()
> >> [-5, 639]
> ax.get_ylims()
> >> [479.5, -0.5]
> 
> ax.set_ylims(ymin, ymax) seems to work, until you use the Image artist. 
> The image flips upside down when you do this.
> 
> I first noticed it when I called ax.imshow(image) and an image was right 
> side up. When I called set_ylims(ymin, ymax), it flipped upside down. 
> It was rightside up if I called set_ylims(ymax, ymin)
> 
> Workaround: simply reverse the limits when using set_lims or get_lims
> 
> Affected:
> Images
> Axes
> Axes documentation (where get_ylims is described as get_ylims(ymin, ymax) )
> 
> Sorry for not sending this to the right place,
> -Conrad Ammon
Conrad,
It is just as well to start out with a mailing list in a case like this.
What you have found is a very confusing aspect of the variable naming 
and the documentation, not a bug in the code itself. It has always been 
part of the mpl design that set_ylim and set_xlim are really setting the 
 bottom and top values, and the left and right values, in that order, 
and not the min and max.
To compound the confusion, images are inverted by default; row number 
increases from top to bottom.
See also the methods invert_yaxis, set_ybound, etc.
Eric

I can't figure out sourceforge's interface to submit a ticket, so I'm 
mailing this to the devel list. That'll give you a sense of my urgency ;- 
)
Subject: Axes Ylims are reversed
Version: 0.98.3
when calling get_xlims(), the values returned are in increasing order: 
[xmin, xmax]. With get_ylims() however, it is reversed.
# make axes in figure, named ax
ax.get_xlims()
>> [-5, 639]
ax.get_ylims()
>> [479.5, -0.5]
ax.set_ylims(ymin, ymax) seems to work, until you use the Image artist. 
The image flips upside down when you do this.
I first noticed it when I called ax.imshow(image) and an image was right 
side up. When I called set_ylims(ymin, ymax), it flipped upside down. It 
was rightside up if I called set_ylims(ymax, ymin)
Workaround: simply reverse the limits when using set_lims or get_lims 
Affected:
Images
Axes
Axes documentation (where get_ylims is described as get_ylims(ymin, ymax) 
)
Sorry for not sending this to the right place,
-Conrad Ammon

Hi all,
 I think I have finally found a nice way to implement step-plots with
different linestyles. The way this is done required some re-writing of
lines.py, but I think it is done in a consistent manner:
 A new property *drawstyle* is introduced. By default this just
connects the datapoints by a straight line. It can be set to "steps-***"
to create step-plots. So, the important point is that "steps-***" is no
longer a linestyle and thus it is possible to set the linestyle
independently. Additionally one can set a combined line- and drawstyle,
e.g. linestyle='steps-mid:'.
 The drawstyle property has the advantage, that one can add other ways
to draw the data naturally, for example one can think of a drawstyle
"bspline" that connects data-points using a spline, or something like a
moving-mean plot.
 The patch is applied and also an example and its output. If there are
no objections, I will commit the patch soon.
Any comments ???
Manuel

On Thu, Sep 18, 2008 at 2:33 PM, Russell E. Owen <rowen@u.washington.edu> wrote:
> The versions of pytz and dateutil that are included with matplotlib
> 0.98.3 are outdated.
>
> dateutil 1.2 is included, but 1.4.1 is available
> pytz: 2008c (from pypi)
>
> I am against including them at all (especially if they are installed
> even if the user already has the packages available). They are both
> trivial to install from source.
>
> In the case of pytz one can also use easy_install (and presumably this
> can happen automatically via dependency handling). Unfortunately that is
> not a good idea for dateutil; I just tried it and got version 1.1. Yow.
Hey Russell, thanks for the head's up.
For our source installs, by default we install them only if they are
not on the system, but you can configure this with setup.cfg to
always, never or conditionally install them.
I have updated the mpl versions to the ones you point to above.
svn users -- if you want to upgrade to the latest using the mpl
versions, cp setup.cfg.template to setup.cfg, uncomment the following
lines, and set them to True
 ## Date/timezone support:
 pytz = True
 dateutil = True
Conversely, if you never want to use the mpl versions, uncomment them
and set them to False.
Unfortunately, our binary installers are not so smart. It would be
nice to have better binary installers which override existing
installations. Charlie, do you know anything about this?
JDH

The versions of pytz and dateutil that are included with matplotlib 
0.98.3 are outdated.
dateutil 1.2 is included, but 1.4.1 is available
pytz: 2008c (from pypi)
I am against including them at all (especially if they are installed 
even if the user already has the packages available). They are both 
trivial to install from source.
In the case of pytz one can also use easy_install (and presumably this 
can happen automatically via dependency handling). Unfortunately that is 
not a good idea for dateutil; I just tried it and got version 1.1. Yow.
-- Russell

Michael Droettboom <md...@st...> writes:
> That's a cool feature, and one I have not come across before.
I agree that it's a neat idea. However, I would prefer a way to specify
color mixtures that is not based on parsing strings but on Python data
structures, e.g. instead of
>> fc="orange!20!white", # 20% orange + 80% white
I would prefer something like the following options:
 fc={'orange': 20, 'white': None}
 fc=[[20, 'orange'], [None, 'white']]
 fc=ColorMixture('orange', 20, 'white') # where ColorMixture is a fairly
 # trivial class
This way we could make mixtures of any color specifications. (What if
you wanted to specify a mixture of mixtures? This situation might not
arise in user code directly, but what if the user is programmatically
creating colors?)
>> fc="aqua!50!green!20!white",
So this would be something like
 fc={'aqua': 50, 'green': 20, 'white': None}
 fc=[[50, 'aqua'], [20, 'green'], [None, 'white']]
 fc=ColorMixture('aqua', 50, 'green', 20, 'white')
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Thanks for the positive feedback!
Okay, I'll add a proper documentation for it and upload the patch again.
-JJ
On Thu, Sep 18, 2008 at 9:47 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Sep 18, 2008 at 8:35 AM, Michael Droettboom <md...@st...> wrote:
>> That's a cool feature, and one I have not come across before.
>>
>> I hesitate slightly because this it is non-standard (by that, I mean not
>> available in a lot of "mainstream" formats like CSS, SVG etc.), but
>> maybe that's just because they aren't as cool as matplotlib... ;) The
>> nice thing is that the "!" isn't meaningful in color strings at present,
>> so this new syntax is at least unambiguous with anything pre-existing.
>>
>> I'm for it, but would like to hear from others first.
>
> I like it too -- I only ask Jae-Joon that you make sure it is properly
> documented, eg in the matplotlib.colors docstring. What would be
> really nice would be a section in doc/users_guide on mpl colors....
>
> JDH
>

I can't seem to find a link to the new (and wonderful) sphinx docs from the
MPL homepage. Are you deliberately waiting to make them "prime"?

On Thu, Sep 18, 2008 at 8:35 AM, Michael Droettboom <md...@st...> wrote:
> That's a cool feature, and one I have not come across before.
>
> I hesitate slightly because this it is non-standard (by that, I mean not
> available in a lot of "mainstream" formats like CSS, SVG etc.), but
> maybe that's just because they aren't as cool as matplotlib... ;) The
> nice thing is that the "!" isn't meaningful in color strings at present,
> so this new syntax is at least unambiguous with anything pre-existing.
>
> I'm for it, but would like to hear from others first.
I like it too -- I only ask Jae-Joon that you make sure it is properly
documented, eg in the matplotlib.colors docstring. What would be
really nice would be a section in doc/users_guide on mpl colors....
JDH

That's a cool feature, and one I have not come across before.
I hesitate slightly because this it is non-standard (by that, I mean not 
available in a lot of "mainstream" formats like CSS, SVG etc.), but 
maybe that's just because they aren't as cool as matplotlib... ;) The 
nice thing is that the "!" isn't meaningful in color strings at present, 
so this new syntax is at least unambiguous with anything pre-existing.
I'm for it, but would like to hear from others first.
Cheers,
Mike
Jae-Joon Lee wrote:
> Hello,
>
> Attached is a small patch to add a simple color mix operation support.
> For example, "red!30!white" mixes 30% of red with 70% of white. The
> syntax is borrowed from latex xcolor package
> (http://www.ukern.de/tex/xcolor.html).
> I found it quite handy with the fancy box thing.
>
> plt.text(0.6, 0.5, "test", size=50, rotation=30.,
> bbox = dict(boxstyle="round",
> fc="orange!20!white", # 20% orange + 80% white
> ec="orange!50!white", # 50 % orange + 50% white
> )
> )
>
> plt.text(0.5, 0.4, "test", size=50, rotation=-30.,
> bbox = dict(boxstyle="square",
> fc="aqua!50!green!20!white",
> ec="green!40!white",
> )
> )
>
> Any chance this could be included in matplotlib?
> Regards,
>
> -JJ
> 
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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'm not seeing those messages, but I am seeing significant slowness to 
SVN operations (such as svn status). 
John Hunter wrote:
> On Wed, Sep 17, 2008 at 1:44 PM, Ryan May <rm...@gm...> wrote:
> 
>> Hi,
>>
>> Is anyone else seeing some odd messages when trying to use SVN right
>> now? Here's what I see:
>>
>> 
>
> I just did an svn up w/o incident
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> 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

Thanks John,
Everything seems fine.
Thanks again,
-JJ
On Wed, Sep 17, 2008 at 4:53 PM, John Hunter <jd...@gm...> wrote:
> On Wed, Sep 17, 2008 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
>>>> I uploaded my patch.
>>>>
>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
>
> OK, I've applied it. I reformatted some of the docstrings and
> incorporated a bunch of the comments into the docstrings because they
> will probably be helpful there to users reading the docs to figure out
> what is going on. Let me know if this creates any problems, and
> thanks again for the very nice patch and examples.
>
> JDH
>

Mike et al.,
You can ignore my message. Something is wrong with my numpy 
installation--an old version is being found. The fact that the problem 
started when I updated sphinx, and it did something with easy_install, 
makes me wonder whether that is what started the trouble. I haven't 
figured it out yet.
Eric
Eric Firing wrote:
> Mike,
> 
> After updating sphinx to 66492 from svn, I can't build the mpl docs:
> 
> efiring@manini:~/programs/py/mpl/mpl_trunk/doc$ python make.py
> Extension error:
> Could not import extension mathmpl (exception: No module named ma)
> Building HTML failed.
> 
> Any idea what the problem is?
> 
> Thanks.
> 
> Eric
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello,
Attached is a small patch to add a simple color mix operation support.
For example, "red!30!white" mixes 30% of red with 70% of white. The
syntax is borrowed from latex xcolor package
(http://www.ukern.de/tex/xcolor.html).
I found it quite handy with the fancy box thing.
plt.text(0.6, 0.5, "test", size=50, rotation=30.,
 bbox = dict(boxstyle="round",
 fc="orange!20!white", # 20% orange + 80% white
 ec="orange!50!white", # 50 % orange + 50% white
 )
 )
plt.text(0.5, 0.4, "test", size=50, rotation=-30.,
 bbox = dict(boxstyle="square",
 fc="aqua!50!green!20!white",
 ec="green!40!white",
 )
 )
Any chance this could be included in matplotlib?
Regards,
-JJ

Mike,
After updating sphinx to 66492 from svn, I can't build the mpl docs:
efiring@manini:~/programs/py/mpl/mpl_trunk/doc$ python make.py
Extension error:
Could not import extension mathmpl (exception: No module named ma)
Building HTML failed.
Any idea what the problem is?
Thanks.
Eric

On Wed, Sep 17, 2008 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>> I uploaded my patch.
>>>
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
OK, I've applied it. I reformatted some of the docstrings and
incorporated a bunch of the comments into the docstrings because they
will probably be helpful there to users reading the docs to figure out
what is going on. Let me know if this creates any problems, and
thanks again for the very nice patch and examples.
JDH

s
On Wed, Sep 17, 2008 at 2:50 PM, Jae-Joon Lee <lee...@gm...> wrote:
> One thing I forgot to mention is that, in the Text class, draw()
> method calls _draw_bbox() method. If I call the _draw_bbox() methods
> after gc in draw() is created, then _draw_bbox call somehow changes
> the gc in the original draw() method, which I think is not supposed to
> happen. I haven't looked at this carefully, but this might only happen
> in some specific backends (I'm using GtkCairo). Anyhow, as a
> workaround, in the draw() method, _draw_bbox() is called before the gc
> is created.
I am not sure why the gc is being modified, but an alternative is to
get a new gc and then copy the properties
 newgc = renderer.new_gc()
 newgc.copy_properties(oldgc)
This might be a less brittle solution since in the distant future we
may not remember why the drawing order had t be the way it is.
JDH
JDH

One thing I forgot to mention is that, in the Text class, draw()
method calls _draw_bbox() method. If I call the _draw_bbox() methods
after gc in draw() is created, then _draw_bbox call somehow changes
the gc in the original draw() method, which I think is not supposed to
happen. I haven't looked at this carefully, but this might only happen
in some specific backends (I'm using GtkCairo). Anyhow, as a
workaround, in the draw() method, _draw_bbox() is called before the gc
is created.
On Wed, Sep 17, 2008 at 3:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Thanks John,
>
> I made a single diff file and uploaded it.
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
>
> Regards,
>
> -JJ
>
>
>
>
>
> On Wed, Sep 17, 2008 at 3:01 PM, John Hunter <jd...@gm...> wrote:
>> On Wed, Sep 17, 2008 at 1:30 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>> Hi,
>>>
>>> I uploaded my patch.
>>>
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
>>
>>
>> Hi Jae Joon -- thanks for uploading this. I have read through it once
>> and it looks pretty good -- thanks for doing the extra work to
>> properly document the kwargs using the auto-property infrastructure.
>>
>> One request: could you submit the entire patch including the examples
>> as a single 'svn diff'? Then I can more easily apply it and test it.
>>
>> Thanks,
>> JDH
>>
>

Thanks John,
I made a single diff file and uploaded it.
https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
Regards,
-JJ
On Wed, Sep 17, 2008 at 3:01 PM, John Hunter <jd...@gm...> wrote:
> On Wed, Sep 17, 2008 at 1:30 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> Hi,
>>
>> I uploaded my patch.
>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=2116614&group_id=80706&atid=560722
>
>
> Hi Jae Joon -- thanks for uploading this. I have read through it once
> and it looks pretty good -- thanks for doing the extra work to
> properly document the kwargs using the auto-property infrastructure.
>
> One request: could you submit the entire patch including the examples
> as a single 'svn diff'? Then I can more easily apply it and test it.
>
> Thanks,
> JDH
>