matplotlib-devel Mailing List for matplotlib (Page 3)

On Mon, Nov 8, 2010 at 6:55 PM, Matthew Brett <mat...@gm...> wrote:
> First - thank you - it makes my heart very glad to be able to do this:
>
> .. plot::
>  :include-source:
>
>  import matplotlib.pyplot as plt
>  plt.plot(range(10))
>  plt.show()
>
> Here's my question.  This is already a huge step forward for me, but
> the full monty would be to be able to do:
>
> .. testcode::
>
>  import some_module
>  res = some_module.use_it('a string')
>
> .. plot::
>  :include-source:
>
>  plt.imshow(res)
>
> and so on. I mean, the ability to keep the code context across the
> page, both in the ..plot: and ..testcode:: and even >>> directives, so
> I can build up my tutorial examples on top of the previous results.
> That step would make it the perfect tool for the tutorials that I have
> ready to port - and I am sure - many others.
>
> Is that already possible? If not, how easy would it be? It if isn't
> easy, can y'all give me some pointers as to how to get there?
This is a useful feature I've wanted myself. I just contributed a
change to the plot directive in svn to support this using two new
options :context: and :nofigs:, and updated the sampledoc tutorial.
The relevant bit from the tutorial is in the link below:
 http://matplotlib.sourceforge.net/sampledoc/extensions.html#inserting-matplotlib-plots
Also, we have a really useful ipython directive that is stateful by
default, and includes many options for suppressing input blocks,
doctesting on output blocks, saving figures, and more. It is included
in the ipython src tree. My original proposal is at
http://matplotlib.sourceforge.net/ipymode/_build/html/proposal.html,
which I've implemented with minor changes. A real world working
example from some lecture notes I prepared recently is attached as
convolution.rst, and some notes are below. I need to get this added
to the sampledoc tutorial....
=================
Ipython Directive
=================
The ipython directive is a stateful ipython shell for embedding in
sphinx documents. It knows about standard ipython prompts, and
extracts the input and output lines. These prompts will be renumbered
starting at ``1``. The inputs will be fed to an embedded ipython
interpreter and the outputs from that interpreter will be inserted as
well.
.. ipython::
 In [136]: x = 2
 In [137]: x**3
 Out[137]: 8
The state from previous sessions is stored, and standard error is
trapped. At doc build time, ipython's output and std err will be
inserted, and prompts will be renumbered. So the prompt below should
be ``In [3]:`` in the rendered docs.
.. ipython::
 In [138]: z = x*3 # x is recalled from previous block
 In [139]: z
 Out[139]: 6
 In [140]: print z
 --------> print(z)
 6
 In [141]: q = z[) # this is a syntax error -- we trap ipy exceptions
 ------------------------------------------------------------
 File "<ipython console>", line 1
 q = z[) # this is a syntax error -- we trap ipy exceptions
 ^
 SyntaxError: invalid syntax
The embedded interpeter supports some limited markup. For example,
you can put comments in your ipython sessions, which are reported
verbatim. There are some handy "pseudo-decorators" that let you
doctest the output. The inputs are fed to an embbedded ipython
session and the outputs from the ipython session are inserted into
your doc. If the output in your doc and in the ipython session don't
match on a doctest assertion, an error will be
.. ipython::
 In [1]: x = 'hello world'
 # this will raise an error if the ipython output is different
 @doctest
 In [2]: x.upper()
 Out[2]: 'HELLO WORLD'
 # some readline features cannot be supported, so we allow
 # "verbatim" blocks, which are dumped in verbatim except prompts
 # are continuously numbered
 @verbatim
 In [3]: x.st<TAB>
 x.startswith x.strip
Multi-line input is supported.
.. ipython::
 In [130]: url = 'http://ichart.finance.yahoo.com/table.csv?s=CROX\
 .....: &d=9&e=22&f=2009&g=d&a=1&br=8&c=2006&ignore=.csv'
 In [131]: print url.split('&')
 --------> print(url.split('&'))
 ['http://ichart.finance.yahoo.com/table.csv?s=CROX', 'd=9', 'e=22',
'f=2009', 'g=d', 'a=1', 'b=8', 'c=2006', 'ignore=.csv']
 In [60]: import urllib
You can do doctesting on multi-line output as well. Just be careful
when using non-deterministic inputs like random numbers in the ipython
directive, because your inputs are ruin through a live interpreter, so
if you are doctesting random output you will get an error. Here we
"seed" the random number generator for deterministic output, and we
suppress the seed line so it doesn't show up in the rendered output
.. ipython::
 In [133]: import numpy.random
 @suppress
 In [134]: numpy.random.seed(2358)
 @doctest
 In [135]: np.random.rand(10,2)
 Out[135]:
 array([[ 0.64524308, 0.59943846],
 [ 0.47102322, 0.8715456 ],
 [ 0.29370834, 0.74776844],
 [ 0.99539577, 0.1313423 ],
 [ 0.16250302, 0.21103583],
 [ 0.81626524, 0.1312433 ],
 [ 0.67338089, 0.72302393],
 [ 0.7566368 , 0.07033696],
 [ 0.22591016, 0.77731835],
 [ 0.0072729 , 0.34273127]])
Another demonstration of multi-line input and output
.. ipython::
 In [106]: print x
 --------> print(x)
 jdh
 In [109]: for i in range(10):
 .....: print i
 .....:
 .....:
 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
Most of the "pseudo-decorators" can be used an options to ipython
mode. For example, to setup maptlotlib pylab but suppress the output,
you can do. When using the matplotlib ``use`` directive, it should
occur before any import of pylab. This will not show up in the
rendered docs, but the commands will be executed in the embedded
interpeter and subsequent line numbers will be incremented to reflect
the inputs::
 .. ipython::
 :suppress:
 In [144]: from pylab import *
 In [145]: ion()
.. ipython::
 :suppress:
 In [144]: from pylab import *
 In [145]: ion()
Likewise, you can set ``:doctest:`` or ``:verbatim:`` to apply these
settings to the entire block.
You can create one or more pyplot plots and insert them with the
``@savefig`` decorator.
.. ipython::
 @savefig plot_simple.png width=4in
 In [151]: plot([1,2,3]);
 # use a semicolon to suppress the output
 @savefig hist_simple.png width=4in
 In [151]: hist(np.random.randn(10000), 100);
In a subsequent session, we can update the current figure with some
text, and then resave
.. ipython::
 In [151]: ylabel('number')
 In [152]: title('normal distribution')
 @savefig hist_with_text.png
 In [153]: grid(True)

On Monday, November 8, 2010, Michael Droettboom <md...@st...> wrote:
>
>
>
>
>
>
> Should be fixed in r8778, r8779.
>
> Mike
>
> On 11/08/2010 11:13 AM, Michael Droettboom wrote:
>
>
>
> On 11/08/2010 10:34 AM, Benjamin Root wrote:
> I have come across an odd bug in PolarAxes event
> handling. If one creates a polar axes, then attempts to do a
> zoom action (is this even allowed?), and then attempts to do a
> pan (is this even allowed?), errors get thrown.
> Rubber-band zooming is not allowed, but panning is. Panning mode
> allows for zooming (sounds counter-intuitive in English, but it
> makes more sense in the interface that way). That mode also
> allows for dragging the r-labels.
>  Digging deeper, I noticed that the error being
> thrown is from "drag_zoom", which is odd because the current
> action should be drag_pan. Note that this bug only occurs if a
> zoom was attempted prior to a pan. Tracing the code execution,
> I can see that drag_pan does get called before drag_zoom, which
> leads me to suspect that the callbacks were never disconnected.
>
> Quite possibly. I wrote the polar panning code -- but never
> tested this interaction with rubber-band zooming, because the
> latter isn't supposed to do anything anyway.
>
> I don't have enough experience in this area to get much
> further. Can anybody else figure out why the interactive
> panning and zooming are not working for polar plots? There does
> appear to be code for that purpose, but nothing happens for
> either. Maybe it is linked to this bug? Maybe some code point
> is being skipped that would connect and disconnect the proper
> callbacks? I am not sure what is going on here. I have
> attached a really simple script to create a polar plot for
> others to test this out.
>
> I was able to confirm this and will look into it further.
>
> Cheers,
> Mike
>
> Note: I am using GTKAgg backend.
>
> Steps to reproduce:
> 1. Run script
> 2. Click on zoom button.
> 3. Click anywhere inside the polar plot (dragging is not
> needed).
> 4. Click on pan button
> 5. Click and drag inside the polar plot.
>
> Ben Root
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
>
>
Thanks, that seems to do the trick. What is it that one can do anyway
with this pan/zoom mode? All I seem to be able to do is move the
labeling for the radial distance.
Thanks,
Ben

Hi,
First - thank you - it makes my heart very glad to be able to do this:
.. plot::
 :include-source:
 import matplotlib.pyplot as plt
 plt.plot(range(10))
 plt.show()
Here's my question. This is already a huge step forward for me, but
the full monty would be to be able to do:
.. testcode::
 import some_module
 res = some_module.use_it('a string')
.. plot::
 :include-source:
 plt.imshow(res)
and so on. I mean, the ability to keep the code context across the
page, both in the ..plot: and ..testcode:: and even >>> directives, so
I can build up my tutorial examples on top of the previous results.
That step would make it the perfect tool for the tutorials that I have
ready to port - and I am sure - many others.
Is that already possible? If not, how easy would it be? It if isn't
easy, can y'all give me some pointers as to how to get there?
Thanks again,
Matthew

On Mon, Nov 8, 2010 at 1:29 PM, Sandro Tosi <mo...@de...> wrote:
> What's the plan about 1.0.1? is it going to be release soon? will it
> include the sample_data dir in the released tarball, so that we can
> set examples.download = False, and examples.directory =
> "..../sample_data" inside the tarball? that would really help getting
> mpl 1.0.* into Debian.
I will try and get to the release ASAP and set the sample_data up this way...
JDH

Hi all,
On Sun, Nov 7, 2010 at 09:25, Jouni K. Seppänen <jk...@ik...> wrote:
> Jouni K. Seppänen <jk...@ik...> writes:
>
>> Benjamin Root <ben...@ou...> writes:
>>
>>>> As an Ubuntu user, I would really a mechanism
>>>> for excluding examples requiring downloaded data from being built
>>>
>>> How far did we get on that? I could have sworn we did something
>>> about the caching mechanism.
>>
>> I'll commit something simple to deal with this, since the fancier
>> plans were apparently too much.
>
> So now on the 1.0 maintenance branch (coming soon to trunk, once I'm
> done wrangling with svnmerge) you can set new rc parameters
> examples.download to False and examples.directory to the directory where
> you have a checkout of the sample data1. Then get_sample_data will only
> look in this directory and not download anything.
>
> Does this help with the Debian and Ubuntu builds?
Yes, indeed, thanks! I was in fact just working on preparing a patch
again "vanilla" 1.0.0 to be included in Debian package, but then I
realized that I have to provide those sample data, downloading them
from the internet before the build and ship them in the debian
customization of the released tarball... then I stop.
What's the plan about 1.0.1? is it going to be release soon? will it
include the sample_data dir in the released tarball, so that we can
set examples.download = False, and examples.directory =
"..../sample_data" inside the tarball? that would really help getting
mpl 1.0.* into Debian.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Should be fixed in r8778, r8779.
Mike
On 11/08/2010 11:13 AM, Michael Droettboom wrote:
> On 11/08/2010 10:34 AM, Benjamin Root wrote:
>> I have come across an odd bug in PolarAxes event handling. If one 
>> creates a polar axes, then attempts to do a zoom action (is this even 
>> allowed?), and then attempts to do a pan (is this even allowed?), 
>> errors get thrown.
> Rubber-band zooming is not allowed, but panning is. Panning mode 
> allows for zooming (sounds counter-intuitive in English, but it makes 
> more sense in the interface that way). That mode also allows for 
> dragging the r-labels.
>> Digging deeper, I noticed that the error being thrown is from 
>> "drag_zoom", which is odd because the current action should be 
>> drag_pan. Note that this bug only occurs if a zoom was attempted 
>> prior to a pan. Tracing the code execution, I can see that drag_pan 
>> does get called before drag_zoom, which leads me to suspect that the 
>> callbacks were never disconnected.
> Quite possibly. I wrote the polar panning code -- but never tested 
> this interaction with rubber-band zooming, because the latter isn't 
> supposed to do anything anyway.
>>
>> I don't have enough experience in this area to get much further. Can 
>> anybody else figure out why the interactive panning and zooming are 
>> not working for polar plots? There does appear to be code for that 
>> purpose, but nothing happens for either. Maybe it is linked to this 
>> bug? Maybe some code point is being skipped that would connect and 
>> disconnect the proper callbacks? I am not sure what is going on 
>> here. I have attached a really simple script to create a polar plot 
>> for others to test this out.
> I was able to confirm this and will look into it further.
>
> Cheers,
> Mike
>>
>> Note: I am using GTKAgg backend.
>>
>> Steps to reproduce:
>> 1. Run script
>> 2. Click on zoom button.
>> 3. Click anywhere inside the polar plot (dragging is not needed).
>> 4. Click on pan button
>> 5. Click and drag inside the polar plot.
>>
>> Ben Root
>>
>>
>> ------------------------------------------------------------------------------
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 11/08/2010 10:34 AM, Benjamin Root wrote:
> I have come across an odd bug in PolarAxes event handling. If one 
> creates a polar axes, then attempts to do a zoom action (is this even 
> allowed?), and then attempts to do a pan (is this even allowed?), 
> errors get thrown.
Rubber-band zooming is not allowed, but panning is. Panning mode allows 
for zooming (sounds counter-intuitive in English, but it makes more 
sense in the interface that way). That mode also allows for dragging 
the r-labels.
> Digging deeper, I noticed that the error being thrown is from 
> "drag_zoom", which is odd because the current action should be 
> drag_pan. Note that this bug only occurs if a zoom was attempted 
> prior to a pan. Tracing the code execution, I can see that drag_pan 
> does get called before drag_zoom, which leads me to suspect that the 
> callbacks were never disconnected.
Quite possibly. I wrote the polar panning code -- but never tested this 
interaction with rubber-band zooming, because the latter isn't supposed 
to do anything anyway.
>
> I don't have enough experience in this area to get much further. Can 
> anybody else figure out why the interactive panning and zooming are 
> not working for polar plots? There does appear to be code for that 
> purpose, but nothing happens for either. Maybe it is linked to this 
> bug? Maybe some code point is being skipped that would connect and 
> disconnect the proper callbacks? I am not sure what is going on 
> here. I have attached a really simple script to create a polar plot 
> for others to test this out.
I was able to confirm this and will look into it further.
Cheers,
Mike
>
> Note: I am using GTKAgg backend.
>
> Steps to reproduce:
> 1. Run script
> 2. Click on zoom button.
> 3. Click anywhere inside the polar plot (dragging is not needed).
> 4. Click on pan button
> 5. Click and drag inside the polar plot.
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

> > So now on the 1.0 maintenance branch (coming soon to trunk, once I'm
> > done wrangling with svnmerge) you can set new rc parameters
> > examples.download to False and examples.directory to the directory
> > 
> How would one set these during the build process? Is there a way to pass
> in rc parameters via environment variable? Perhaps we should just patch
> matplotlibrc.template in the tree? Any ideas would be appreciated,
I can't check right now how the doc build works, but I think you could either patch the build script to set the parameters programmatically or drop a matplotlibrc file in the relevant directory.
Jouni

On 2010年11月07日 10:25:13 +0200, Jouni K. Seppänen <jk...@ik...> wrote:
> So now on the 1.0 maintenance branch (coming soon to trunk, once I'm
> done wrangling with svnmerge) you can set new rc parameters
> examples.download to False and examples.directory to the directory where
> you have a checkout of the sample data1. Then get_sample_data will only
> look in this directory and not download anything.
> 
How would one set these during the build process? Is there a way to pass
in rc parameters via environment variable? Perhaps we should just patch
matplotlibrc.template in the tree? Any ideas would be appreciated,
- Ben

On Sun, Nov 7, 2010 at 3:25 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> So now on the 1.0 maintenance branch (coming soon to trunk, once I'm
> done wrangling with svnmerge) you can set new rc parameters
> examples.download to False and examples.directory to the directory where
> you have a checkout of the sample data1. Then get_sample_data will only
> look in this directory and not download anything.
>
> Does this help with the Debian and Ubuntu builds?
>
I believe that should help. Hopefully someone on the bug with more
knowledge of the policy will comment to confirm.
- Ben

Jouni K. Seppänen <jk...@ik...> writes:
> Benjamin Root <ben...@ou...> writes:
>
>>> As an Ubuntu user, I would really a mechanism
>>> for excluding examples requiring downloaded data from being built 
>>
>> How far did we get on that? I could have sworn we did something
>> about the caching mechanism. 
>
> I'll commit something simple to deal with this, since the fancier
> plans were apparently too much.
So now on the 1.0 maintenance branch (coming soon to trunk, once I'm
done wrangling with svnmerge) you can set new rc parameters
examples.download to False and examples.directory to the directory where
you have a checkout of the sample data1. Then get_sample_data will only
look in this directory and not download anything.
Does this help with the Debian and Ubuntu builds?
1 https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Benjamin Root <ben...@ou...> writes:
>> As an Ubuntu user, I would really a mechanism
>> for excluding examples requiring downloaded data from being built 
>
> How far did we get on that? I could have sworn we did something
> about the caching mechanism. 
I think there were some discussions (something to do with the transition
to git, and putting test results in the same mechanism), but at least I
never got around to writing any code, and then got distracted by my day
job. I'll commit something simple to deal with this, since the fancier
plans were apparently too much.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Saturday, November 6, 2010, Ben Gamari <bga...@gm...> wrote:
> Hey all,
>
> Not so long ago there was a brief discussion concerning the release
> schedule for 1.0.1[1]. As an Ubuntu user, I would really a mechanism
> for excluding examples requiring downloaded data from being built for
> the doc target. This would bring matplotlib into compliance with
> Debian packaging policy[3].
>
> Cheers,
>
> - Ben
>
>
> [1] http://sourceforge.net/mailarchive/forum.php?thread_name=01aa01cb76eb0ドルd1d7ea027587ドルbe0$%40net&forum_name=matplotlib-devel
> [2] https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/607395
> [3] http://thread.gmane.org/gmane.comp.python.matplotlib.devel/8865
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
How far did we get on that? I could have sworn we did something
about the caching mechanism. What exactly still remains to be done to
be in compliance? Lastly, I am not 100% familiar with the doc build
system, but does't simply check to see if there are newer code?
Couldn't that simply be disabled?
Ben Root

Hey all,
Not so long ago there was a brief discussion concerning the release
schedule for 1.0.1[1]. As an Ubuntu user, I would really a mechanism
for excluding examples requiring downloaded data from being built for
the doc target. This would bring matplotlib into compliance with
Debian packaging policy[3].
Cheers,
- Ben
[1] http://sourceforge.net/mailarchive/forum.php?thread_name=01aa01cb76eb0ドルd1d7ea027587ドルbe0$%40net&forum_name=matplotlib-devel
[2] https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/607395
[3] http://thread.gmane.org/gmane.comp.python.matplotlib.devel/8865

On 11/04/2010 02:38 PM, Jae-Joon Lee wrote:
> On Fri, Nov 5, 2010 at 9:19 AM, Jae-Joon Lee<lee...@gm...> wrote:
>> Eric, it seems to be happened because the "_original_facecolor"
>> property that you introduced is not initialized in __init__ method but
>> in the set_facecolor method. Is there any reason that this cannot be
>> initialized in the __init__ method?
>>
As you found, it is initialized in the __init__ method when 
set_facecolor is called there. In general, I like using the "set" 
methods in __init__ when possible so as to reduce code duplication, and 
so as to make the setting of a parameter work the same with a "set" 
method as it does upon initialization.
>
> Just to clarify, I first thought it is better to be initialized in the
> __init__ method (since then you don't need to worry about it when you
> override set_facecolor method), but after second thought, this may not
> be necessary.
It looks to me like your fix of the demo is the correct way to handle 
the problem.
Eric
>
> -JJ
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, Nov 5, 2010 at 9:19 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Eric, it seems to be happened because the "_original_facecolor"
> property that you introduced is not initialized in __init__ method but
> in the set_facecolor method. Is there any reason that this cannot be
> initialized in the __init__ method?
>
Just to clarify, I first thought it is better to be initialized in the
__init__ method (since then you don't need to worry about it when you
override set_facecolor method), but after second thought, this may not
be necessary.
-JJ

This seems to be related to the recent change by Eric.
I just submitted a modified version of demo_text_path.py.
Eric, it seems to be happened because the "_original_facecolor"
property that you introduced is not initialized in __init__ method but
in the set_facecolor method. Is there any reason that this cannot be
initialized in the __init__ method?
Regards,
-JJ
On Fri, Nov 5, 2010 at 4:14 AM, John Hunter <jd...@gm...> wrote:
> Appears to be branch and trunk
>
> johnh@udesktop191:pylab_examples> python demo_text_path.py
> Traceback (most recent call last):
> File "demo_text_path.py", line 71, in ?
>  transform=IdentityTransform())
> File "demo_text_path.py", line 27, in __init__
>  mpatches.PathPatch.__init__(self, path, **kwargs)
> File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/patches.py",
> line 736, in __init__
>  Patch.__init__(self, **kwargs)
> File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/patches.py",
> line 93, in __init__
>  self.set_fill(fill)
> File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/patches.py",
> line 316, in set_fill
>  self.set_facecolor(self._original_facecolor)
> AttributeError: 'PathClippedImagePatch' object has no attribute
> '_original_facecolor'
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Appears to be branch and trunk
johnh@udesktop191:pylab_examples> python demo_text_path.py
Traceback (most recent call last):
 File "demo_text_path.py", line 71, in ?
 transform=IdentityTransform())
 File "demo_text_path.py", line 27, in __init__
 mpatches.PathPatch.__init__(self, path, **kwargs)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/patches.py",
line 736, in __init__
 Patch.__init__(self, **kwargs)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/patches.py",
line 93, in __init__
 self.set_fill(fill)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/patches.py",
line 316, in set_fill
 self.set_facecolor(self._original_facecolor)
AttributeError: 'PathClippedImagePatch' object has no attribute
'_original_facecolor'