matplotlib-users Mailing List for matplotlib (Page 5)

Hi,
  I am trying to improve my code where I cannot find out why matplotlib-1.1.0 does not
support colors specified as RG tuples. Here is an example.



import numpy as np
import matplotlib.pyplot as plt

_nums = [160.0, 160.0, 160.0, 95.0, 160.0, 160.0]
_colors = [(0.5019607843137255, 0.0, 0.5019607843137255), (0.5019607843137255, 0.0, 0.5019607843137255), (0.5019607843137255, 0.0, 0.5019607843137255), (0.5019607843137255, 0.0, 0.5019607843137255), (0.5019607843137255, 0.0, 0.5019607843137255), (0.5019607843137255, 0.0, 0.5019607843137255)]
_legends = ['foo', 'foo', 'foo', 'blah', 'foo', 'foo']

plt.hist(_nums, histtype='bar', align='mid', color=_colors, log=False, label=_legends)

plt.show()


The above code gives me:

  File "/usr/lib64/python2.7/site-packages/matplotlib/pyplot.py", line 2332, in hist
    ret = ax.hist(x, bins, range, normed, weights, cumulative, bottom, histtype, align, orientation, rwidth, log, color, label, **kwargs)
  File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 7598, in hist
    raise ValueError("color kwarg must have one color per dataset")
ValueError: color kwarg must have one color per dataset


Mainly, I am suggesting the error message to be improved and to write out how many
items were in data, color and legend iterables passed to the function. That would help
in some cases albeit not with this example. That needs some other fix. ;)

I would like that one can also pass in a list of HTML-like colors, e.g. 'F0F8FF' or 0xF0F8FF
would be valid.

Thanks for your comments,
Martin

Thanks for a response, but unfortunately it doesn't seem to work. I have
some sample code on pastebin http://pastebin.com/W6JmbCsz in case the
following does not email out well

# -*- coding: utf-8 -*-
"""
Created on Thu Apr 12 11:16:03 2012

Using the current stable version of pythonxy on Windows 7 32bit
Author: Jonathan


Notice how the figure box is not placed correctly, effectively missing the
legend entirely
"""

import matplotlib.pyplot as plt
import numpy as np

x = np.arange(-2*np.pi, 2*np.pi, 0.1)
fig = plt.figure(1, figsize=(8,6))
ax = fig.add_subplot(111)
ax.plot(x, np.sin(x), label='Sine')
ax.plot(x, np.cos(x), label='Cosine')
ax.plot(x, np.arctan(x), label='Inverse tan')
handles, labels = ax.get_legend_handles_labels()
lgd = ax.legend(handles, labels, loc=9, bbox_to_anchor=(0.5,-0.1))
ax.grid('on')
#fig.tight_layout()
fig.savefig('samplefigure', bbox_extra_artists=(lgd,), bbox='tight')


On Thu, Apr 12, 2012 at 11:51 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Thu, Apr 12, 2012 at 2:05 AM, Jonathan Bruck <jdt...@gm...>wrote:
>
>> Hi all,
>>
>> Forgive me as this is the first time I've posted here. I've asked a
>> question on StackOverFlow:
>>
>>
>> http://stackoverflow.com/questions/10101700/moving-matplotlib-legend-outside-of-the-axis-makes-it-cutoff-by-the-figure-box#comment12952803_10101700
>>
>> The question relates to adjusting the size of the figure box to
>> accommodate a large legend when the legend is placed below instead of on
>> top of the axes.
>>
>> I thought I'd post here to see if there are any other answers to avoiding
>> having the figure box cut off the bottom of the legend.
>>
>> Thanks
>>
>> Jonathan
>> --
>> There are no passengers on Spaceship Earth.  We are all crew.
>>
>> E: jdt...@gm...
>>
>>
> If you only care about saving the figure, the savefig() method can take
> bbox='tight' and bbox_extra_artists=[legnd_obj] arguments (assuming you
> save the legend to such a variable.  As for on-screen displays, I have yet
> to find a solution.
>
> Ben Root
>
>


-- 
There are no passengers on Spaceship Earth.  We are all crew.

Jonathan Bruck
E: jdt...@gm...
Mob: 0421188951
Bachelor of Engineering (Mechanical, Biomedical), Bachelor of Medical
Science
--

Hi all ,
Apologies if this was already posted here ..but there is video of John
Hunters advanced tutorial from the pydata conference 2012 courtesy Markana
 at

http://marakana.com/s/advanced_matplotlib_tutorial_with_library_author_john_hunter,1133/index.html#c132880

The link to the tutorial files is
http://bit.ly/Ancxno

Thanks
Hari

Actually I don't know about the apple supplied python, but I believe enthoughts python is installed as a framework. 

C



On Apr 12, 2012, at 8:53 PM, Michiel de Hoon <mjl...@ya...> wrote:

> --- On Wed, 4/11/12, Zachary Pincus <zac...@ya...> wrote:
>> Hopefully someone who knows more about the OS X backend can
>> comment here...
> 
> It sounds like the Python you are using is not installed as a framework. Using the --enable-framework flag when compiling Python.
> 
> -Michiel.
> 
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

When the -|> style was added to FancyArrowPatch, the purpose was to add 
an arrow style with a certain style shaft, but a solid head [1]. 
However, since the given linestyle is used for the outline of the head, 
we can have arrowheads that look very odd.  Here is the example input 
and output:

http://aleph.sagemath.org/?q=0b7e7b41-e6cc-4cfe-b176-e42ece3565c9

from matplotlib.pyplot import figure, show
from matplotlib.patches import FancyArrowPatch

fig = figure()
ax = fig.add_subplot(111,autoscale_on=False,)
p = FancyArrowPatch((0,0), (1,1), 
arrowstyle='-|>,head_width=8,head_length=16',lw=3,fc='k',ec='k',linestyle='dashed')
ax.add_patch(p)
show()

Is there an easy fix to make the arrowhead have a solid linestyle, even 
if the shaft is dashed?  Is this desirable to anyone else besides me?

Thanks,

Jason

[1] http://sourceforge.net/mailarchive/message.php?msg_id=21133511

--- On Wed, 4/11/12, Zachary Pincus <zac...@ya...> wrote:
> Hopefully someone who knows more about the OS X backend can
> comment here...

It sounds like the Python you are using is not installed as a framework. Using the --enable-framework flag when compiling Python.

-Michiel.

On Thu, Apr 12, 2012 at 5:20 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Thu, Mar 29, 2012 at 5:53 AM, Christopher Graves <
> chr...@gm...> wrote:
>
>>
>>
>> On Tue, Mar 27, 2012 at 3:31 AM, Mike Kaufman <mc...@gm...> wrote:
>>
>>> On 3/26/12 12:49 PM, Christopher Graves wrote:
>>>
>>>> On Sun, Mar 11, 2012 at 2:32 PM, Christopher Graves
>>>> <chr...@gm... <mailto:chr...@gm...>> wrote:
>>>>
>>>
>>>         Try this:
>>>>
>>>>        from pylab import *
>>>>        from matplotlib.ticker import AutoMinorLocator
>>>>
>>>>        clf()
>>>>        ax=subplot(111)
>>>>        ax.autoscale(tight=True)
>>>>        plot([1,2,4],[1,2,3])
>>>>        ax.xaxis.set_minor_locator(__AutoMinorLocator(2))
>>>>        ax.yaxis.set_minor_locator(__AutoMinorLocator(2))
>>>>
>>>>        draw()
>>>>
>>>>        M
>>>>
>>>>        PS: I believe this is a fairly new feature...
>>>>
>>>>
>>>>    Thanks! Great news that AutoMinorLocator has been added and
>>>>    accomplishes this. Regarding the P.S. I can confirm that the feature
>>>>    was not in matplotlib 1.0.1 - I had to update to 1.1.0 to use it.
>>>>
>>>>    Best /Chris
>>>>
>>>>
>>>>
>>>> Hi Mike,
>>>>
>>>> A follow-up question... When using that, if one then tries to manually
>>>> use the zoom-box tool available with a matplotlib plot, if one draws too
>>>> small of a box (less than 2 major ticks in x or y dimension, based on
>>>> the following error message), it gives the following error and further
>>>> operations on the plot do not work.
>>>>
>>>> ValueError: Need at least two major ticks to find minor tick locations
>>>> ( File "/usr/lib/pymodules/python2.7/matplotlib/ticker.py", line 1528,
>>>> in __call__ )
>>>>
>>>> Any way to avoid this for now? (And ultimately, should this be made into
>>>> a bug fix request?)
>>>>
>>>
>>>
>>> Ok, I seem to remember seeing this error before, but I can't trip it now
>>> (with either 1.1.1rc or today's git checkout of 1.2.x). Do you have
>>> a short script that can reproduce this? For me, the zoom-box tool seems
>>> to be [correctly] setting the majortick locations as I zoom in, thus
>>> preventing this exception. I should note that I'm using the GTKAgg
>>> frontend. This may be the issue. A long time ago I was using the MacOSX
>>> frontend, and maybe this was when I was seeing it...
>>>
>>> Aside from that, this would be a bug.
>>>
>>> M
>>>
>>
>>
>> On Wed, Mar 28, 2012 at 10:50 PM, Christopher Graves <
>> chr...@gm...> wrote:
>>
>>> Hi Mike,
>>>
>>> Ok I found the root cause. Here is a short script:
>>>
>>>
>>> from pylab import *
>>>
>>> from matplotlib.ticker import MultipleLocator, AutoMinorLocator
>>>
>>> plot([0,3],[0,2.2])
>>>
>>> ax = gca()
>>>
>>> ax.xaxis.set_major_locator(MultipleLocator(0.5))
>>>
>>> ax.xaxis.set_minor_locator(AutoMinorLocator(2))
>>>
>>> show()
>>>
>>>
>>> Once MultipleLocator has been called, the auto-reassigning of tick
>>> spacing when zooming (either with the zoom box or the cross and right-click
>>> drag) does not happen, and then AutoMinorLocator has the error because it
>>> has "majorstep = majorlocs[1] - majorlocs[0]" and majorlocs has less than 2
>>> elements when zoomed in that far. (GTKAgg vs others doesn't matter.)
>>>
>>> Seems like a bug. Is it the same in the newer mpl version you have?
>>> For my purposes, a different fix could work, because my reason to use
>>> MultipleLocator is only to make x and y major ticks have equal spacing, as
>>> follows:
>>>
>>> from pylab import *
>>>
>>> from matplotlib.ticker import MultipleLocator, AutoMinorLocator
>>>
>>> ax = subplot(111, aspect='equal')
>>>
>>> plot([0,3],[0,1.1])
>>>
>>> # Set the ticks to have the same interval on both x and y axes:
>>>
>>> x_major_tick_interval =
>>> abs(ax.xaxis.get_ticklocs()[0]-ax.xaxis.get_ticklocs()[1])
>>>
>>> ax.yaxis.set_major_locator(MultipleLocator(x_major_tick_interval))
>>>
>>> # 2 minor ticks per major tick:
>>>
>>> ax.yaxis.set_minor_locator(AutoMinorLocator(2))
>>>
>>> ax.xaxis.set_minor_locator(AutoMinorLocator(2))
>>>
>>> show()
>>>
>>>
>>> aspect='equal' is not necessary to bring out the error, it just
>>> illustrates the purpose of this. Is there another way to fix the x and y
>>> tick interval as equal? (And ideally even maintain the equal spacing when
>>> zooming.. As it is, they initially show as equal, but when zooming they can
>>> lose equal visible spacing while maintaining equal value intervals.)
>>>
>>>
>>> Best,
>>>
>>> Chris
>>>
>>
>>
>> On Thu, Mar 29, 2012 at 4:06 AM, Mike Kaufman <mc...@gm...> wrote:
>>
>>> I can confirm this bug on yesterday's checkout. About equal spacing, I
>>> don't know offhand. A question to ask the list I think. If you could,
>>> please file as an issue on the github tracker. Include your code nugget
>>> that reproduces. Thanks.
>>>
>>> I don't have a lot of time at this moment, so hopefully somebody else
>>> looks at fixing it first.
>>>
>>> M
>>>
>>
>>
>> Ok, bug is filed at https://github.com/matplotlib/matplotlib/issues/807
>> I did not realize that our last couple of messages were not sent to the
>> mailing-list.
>>
>> To others on mailing-list:
>> Apart from someone hopefully fixing this bug, does anyone know another
>> way to fix the x and y tick interval as equal, besides the way I did it in
>> the last code block above, which uses
>> "ax.yaxis.set_major_locator(MultipleLocator(x_major_tick_interval))" after
>> plotting?
>> (And ideally even maintain the equal spacing when zooming.. As it is,
>> they initially show as equal, but when zooming they can lose equal visible
>> spacing while maintaining equal value intervals.)
>>
>> Best /Chris
>>
>>
> Sorry for the long delay in responding.  I have a huge backlog of emails
> to get through.
>
> It sounds like you want ax.set_aspect('equal') or something to that
> effect.  That will maintain it even after zooming.
>
> Ben Root
>
>
No problem! I think I mis-communicated the issue. The example I put above
already does have the aspect ratio 'equal', when preparing the plot: "ax =
subplot(111, aspect='equal')"  The equal-aspect is maintained fine while
zooming. What I also want is to have the x and y tick-spacing be equal and
maintained. Making the tick spacing equal works fine in the way I did it in
the example above, but when you zoom with either of the zoom-tools the
tick-spacing is not maintained equal. (The example above can be run without
the 2 lines near the end that have "AutoMinorLocator", to avoid the actual
bug that occurs when zooming due to AutoMinorLocator.)

Best /Chris

El día 12 de abril de 2012 03:46, questions anon
<que...@gm...> escribió:

> I am not sure how to recognise that x-axis are dates like 20110101,
> 20110102, 20110103 etc.

Use datetime objects instead of strings.

Goyo

On Thu, Mar 29, 2012 at 5:53 AM, Christopher Graves <
chr...@gm...> wrote:

>
>
> On Tue, Mar 27, 2012 at 3:31 AM, Mike Kaufman <mc...@gm...> wrote:
>
>> On 3/26/12 12:49 PM, Christopher Graves wrote:
>>
>>> On Sun, Mar 11, 2012 at 2:32 PM, Christopher Graves
>>> <chr...@gm... <mailto:chr...@gm...>> wrote:
>>>
>>
>>         Try this:
>>>
>>>        from pylab import *
>>>        from matplotlib.ticker import AutoMinorLocator
>>>
>>>        clf()
>>>        ax=subplot(111)
>>>        ax.autoscale(tight=True)
>>>        plot([1,2,4],[1,2,3])
>>>        ax.xaxis.set_minor_locator(__AutoMinorLocator(2))
>>>        ax.yaxis.set_minor_locator(__AutoMinorLocator(2))
>>>
>>>        draw()
>>>
>>>        M
>>>
>>>        PS: I believe this is a fairly new feature...
>>>
>>>
>>>    Thanks! Great news that AutoMinorLocator has been added and
>>>    accomplishes this. Regarding the P.S. I can confirm that the feature
>>>    was not in matplotlib 1.0.1 - I had to update to 1.1.0 to use it.
>>>
>>>    Best /Chris
>>>
>>>
>>>
>>> Hi Mike,
>>>
>>> A follow-up question... When using that, if one then tries to manually
>>> use the zoom-box tool available with a matplotlib plot, if one draws too
>>> small of a box (less than 2 major ticks in x or y dimension, based on
>>> the following error message), it gives the following error and further
>>> operations on the plot do not work.
>>>
>>> ValueError: Need at least two major ticks to find minor tick locations
>>> ( File "/usr/lib/pymodules/python2.7/matplotlib/ticker.py", line 1528,
>>> in __call__ )
>>>
>>> Any way to avoid this for now? (And ultimately, should this be made into
>>> a bug fix request?)
>>>
>>
>>
>> Ok, I seem to remember seeing this error before, but I can't trip it now
>> (with either 1.1.1rc or today's git checkout of 1.2.x). Do you have
>> a short script that can reproduce this? For me, the zoom-box tool seems
>> to be [correctly] setting the majortick locations as I zoom in, thus
>> preventing this exception. I should note that I'm using the GTKAgg
>> frontend. This may be the issue. A long time ago I was using the MacOSX
>> frontend, and maybe this was when I was seeing it...
>>
>> Aside from that, this would be a bug.
>>
>> M
>>
>
>
> On Wed, Mar 28, 2012 at 10:50 PM, Christopher Graves <
> chr...@gm...> wrote:
>
>> Hi Mike,
>>
>> Ok I found the root cause. Here is a short script:
>>
>>
>> from pylab import *
>>
>> from matplotlib.ticker import MultipleLocator, AutoMinorLocator
>>
>> plot([0,3],[0,2.2])
>>
>> ax = gca()
>>
>> ax.xaxis.set_major_locator(MultipleLocator(0.5))
>>
>> ax.xaxis.set_minor_locator(AutoMinorLocator(2))
>>
>> show()
>>
>>
>> Once MultipleLocator has been called, the auto-reassigning of tick
>> spacing when zooming (either with the zoom box or the cross and right-click
>> drag) does not happen, and then AutoMinorLocator has the error because it
>> has "majorstep = majorlocs[1] - majorlocs[0]" and majorlocs has less than 2
>> elements when zoomed in that far. (GTKAgg vs others doesn't matter.)
>>
>> Seems like a bug. Is it the same in the newer mpl version you have?
>> For my purposes, a different fix could work, because my reason to use
>> MultipleLocator is only to make x and y major ticks have equal spacing, as
>> follows:
>>
>> from pylab import *
>>
>> from matplotlib.ticker import MultipleLocator, AutoMinorLocator
>>
>> ax = subplot(111, aspect='equal')
>>
>> plot([0,3],[0,1.1])
>>
>> # Set the ticks to have the same interval on both x and y axes:
>>
>> x_major_tick_interval =
>> abs(ax.xaxis.get_ticklocs()[0]-ax.xaxis.get_ticklocs()[1])
>>
>> ax.yaxis.set_major_locator(MultipleLocator(x_major_tick_interval))
>>
>> # 2 minor ticks per major tick:
>>
>> ax.yaxis.set_minor_locator(AutoMinorLocator(2))
>>
>> ax.xaxis.set_minor_locator(AutoMinorLocator(2))
>>
>> show()
>>
>>
>> aspect='equal' is not necessary to bring out the error, it just
>> illustrates the purpose of this. Is there another way to fix the x and y
>> tick interval as equal? (And ideally even maintain the equal spacing when
>> zooming.. As it is, they initially show as equal, but when zooming they can
>> lose equal visible spacing while maintaining equal value intervals.)
>>
>>
>> Best,
>>
>> Chris
>>
>
>
> On Thu, Mar 29, 2012 at 4:06 AM, Mike Kaufman <mc...@gm...> wrote:
>
>> I can confirm this bug on yesterday's checkout. About equal spacing, I
>> don't know offhand. A question to ask the list I think. If you could,
>> please file as an issue on the github tracker. Include your code nugget
>> that reproduces. Thanks.
>>
>> I don't have a lot of time at this moment, so hopefully somebody else
>> looks at fixing it first.
>>
>> M
>>
>
>
> Ok, bug is filed at https://github.com/matplotlib/matplotlib/issues/807
> I did not realize that our last couple of messages were not sent to the
> mailing-list.
>
> To others on mailing-list:
> Apart from someone hopefully fixing this bug, does anyone know another way
> to fix the x and y tick interval as equal, besides the way I did it in the
> last code block above, which uses
> "ax.yaxis.set_major_locator(MultipleLocator(x_major_tick_interval))" after
> plotting?
> (And ideally even maintain the equal spacing when zooming.. As it is, they
> initially show as equal, but when zooming they can lose equal visible
> spacing while maintaining equal value intervals.)
>
> Best /Chris
>
>
Sorry for the long delay in responding.  I have a huge backlog of emails to
get through.

It sounds like you want ax.set_aspect('equal') or something to that
effect.  That will maintain it even after zooming.

Ben Root

On Thu, Apr 12, 2012 at 2:05 AM, Jonathan Bruck <jdt...@gm...> wrote:

> Hi all,
>
> Forgive me as this is the first time I've posted here. I've asked a
> question on StackOverFlow:
>
>
> http://stackoverflow.com/questions/10101700/moving-matplotlib-legend-outside-of-the-axis-makes-it-cutoff-by-the-figure-box#comment12952803_10101700
>
> The question relates to adjusting the size of the figure box to
> accommodate a large legend when the legend is placed below instead of on
> top of the axes.
>
> I thought I'd post here to see if there are any other answers to avoiding
> having the figure box cut off the bottom of the legend.
>
> Thanks
>
> Jonathan
> --
> There are no passengers on Spaceship Earth.  We are all crew.
>
> E: jdt...@gm...
>
>
If you only care about saving the figure, the savefig() method can take
bbox='tight' and bbox_extra_artists=[legnd_obj] arguments (assuming you
save the legend to such a variable.  As for on-screen displays, I have yet
to find a solution.

Ben Root

Hi all,

Forgive me as this is the first time I've posted here. I've asked a
question on StackOverFlow:

http://stackoverflow.com/questions/10101700/moving-matplotlib-legend-outside-of-the-axis-makes-it-cutoff-by-the-figure-box#comment12952803_10101700

The question relates to adjusting the size of the figure box to accommodate
a large legend when the legend is placed below instead of on top of the
axes.

I thought I'd post here to see if there are any other answers to avoiding
having the figure box cut off the bottom of the legend.

Thanks

Jonathan
-- 
There are no passengers on Spaceship Earth.  We are all crew.

E: jdt...@gm...

Hi matplotlib list,
I am having trouble applying mdates in matplotlib.
I am not sure how to recognise that x-axis are dates like 20110101,
20110102, 20110103 etc.
Any feedback will be greatly appreciated!
below is the code I have so far:

import numpy as np
import matplotlib.pyplot as plt
from numpy import ma as MA
from mpl_toolkits.basemap import Basemap
import os
import glob
import matplotlib.dates as mdates

MainFolder=r"E:/Rainfall/rainfall-2011/test/"
OutputFolder=r"E:/test_out/"

rmax=[]
monthyear=[]

for (path, dirs, files) in os.walk(MainFolder):
    path=path+'/'
    for fname in files:
        if fname.endswith('.txt'):
            filename=path+fname
            fileName, fileExtension=os.path.splitext(fname)
            test=fileName.strip('r')
            test=str(test)
            monthyear.append(test)
            f=np.genfromtxt(filename, skip_header=6)
            dailymax=f.max()
            rmax.append(dailymax)
print rmax
print monthyear

x=monthyear
y=rmax

fig, ax=plt.subplots(1)

plt.plot(x,y)

fig.autofmt_xdate()
ax.fmt_xdata=mdates.DateFormatter('%Y%m%d')

plt.ylabel("Precipitation")
plt.title("Max daily Precipition Vic")
plt.savefig(OutputFolder+"MaxdailyPrecip.png")
plt.show()

The 'tkagg' backend works properly for me, (I get the icon, the windows
behave properly, keyboard shortcuts work, etc....) my only complaint is
that it's much "uglier" than the OSX version (the color scheme is wrong as
the windows are non-native).
-E

On Wed, Apr 11, 2012 at 12:22 PM, Ethan Gutmann <eth...@gm...>wrote:

> On Apr 11, 2012, at 2:19 PM, Chris Laumann wrote:
>
> > I get the exact same behavior from both Enthought supplied python and
> Apple supplied python. I haven't tried any other pythons, but it isn't
> limited to the Apple one.
> >
> > C
>
>
> I've never seen quite what has been described, but I've had issues with
> the macosx backend not updating the plot window in realtime when working
> interactively.
>
> I've given up and just use the tkagg backend, no problems there on OSX for
> me. It might be something others should try.  When I was having trouble, I
> tried reinstalling python & matplotlib about 5 different ways including
> just using the builtin python plus the binary matplotlib installer, nothing
> worked with the osx backend, but I think tkagg always worked.
>
> Is there a benefit to the macosx backend over the tkagg one?
>
> Ethan
>
> >
> > On Apr 11, 2012, at 1:58 PM, Elliot Saba wrote:
> >
> >> I'm using homebrew python, which is built from source, and the latest
> matplotlib gotten from git://github.com/matplotlib/matplotlib.git.  (I
> rebuilt it ~2 minutes ago)
> >>
> >> Perhaps there's some kind of environment difference?
> >> -E
> >>
> >> On Wed, Apr 11, 2012 at 5:12 AM, Zachary Pincus <
> zac...@ya...> wrote:
> >>> 1. Keyboard input always goes to the terminal. Shortcuts don't work in
> the standard plot windows and my custom widgets no longer catch
> key_press_events  (I'm not sure when this functionality broke exactly as I
> haven't used those widgets much recently but it worked when I developed 'em
> a year or two ago.)
> >>>
> >>> 2. There's no icon in the cmd-tab task switcher corresponding to the
> figure windows. Swapping to the terminal running ipython (or the qtconsole
> for ipython qtconsole) does not raise the windows.
> >>>
> >>> 3. Using mission control, the figures appear grouped as if they belong
> to an application of their own. However, when you click on them to swap to
> them and bring them forward from behind other windows, they raise and then
> immediately disappear again. I think that mission control is raising the
> specific window you select from the collection of figures, but then OSX is
> somehow immediately re-raising the previously selected app, which hides the
> figures again.
> >>
> >> Hmm, I don't really see these issues, using a dev matplotlib, OS X
> 10.7.3, and a python.org python 2.7. Interesting. (This is with the
> 'MacOSX' backend, mind. Also note that on March 5 there was a patch to that
> backend to fix a few issues, so if your matplotlib checkout is before that,
> perhaps that's the problem?)
> >>
> >> Anyhow, when I start python (or ipython), and then do "import
> matplotlib.pyplot as plt", nothing happens, but then "plt.figure()", for
> example, causes a new dock icon to appear -- a python rocket-ship thing --
> that acts as an "app" that owns the figure windows. I can use this app to
> switch to / raise the windows from the dock or the cmd-tab switcher, and
> things work correctly via mission control as well.
> >>
> >> The keyboard shortcuts are a bit flaky ('s' never seems to work, but I
> can e.g. toggle gridlines with 'g' or log-axes with 'l'), but the
> key-presses definitely don't go to the terminal.
> >>
> >> I wonder what the difference is? Perhaps the apple-supplied python is a
> bit broken in this regard?
> >>
> >> Zach
> >>
> ------------------------------------------------------------------------------
> >> Better than sec? Nothing is better than sec when it comes to
> >> monitoring Big Data applications. Try Boundary one-second
> >> resolution app monitoring today. Free.
> >> http://p.sf.net/sfu/Boundary-dev2dev
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >>
> ------------------------------------------------------------------------------
> >> Better than sec? Nothing is better than sec when it comes to
> >> monitoring Big Data applications. Try Boundary one-second
> >> resolution app monitoring today. Free.
> >>
> http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Apr 11, 2012, at 2:19 PM, Chris Laumann wrote:

> I get the exact same behavior from both Enthought supplied python and Apple supplied python. I haven't tried any other pythons, but it isn't limited to the Apple one.
> 
> C


I've never seen quite what has been described, but I've had issues with the macosx backend not updating the plot window in realtime when working interactively. 

I've given up and just use the tkagg backend, no problems there on OSX for me. It might be something others should try.  When I was having trouble, I tried reinstalling python & matplotlib about 5 different ways including just using the builtin python plus the binary matplotlib installer, nothing worked with the osx backend, but I think tkagg always worked. 

Is there a benefit to the macosx backend over the tkagg one? 

Ethan

> 
> On Apr 11, 2012, at 1:58 PM, Elliot Saba wrote:
> 
>> I'm using homebrew python, which is built from source, and the latest matplotlib gotten from git://github.com/matplotlib/matplotlib.git.  (I rebuilt it ~2 minutes ago)
>> 
>> Perhaps there's some kind of environment difference?
>> -E
>> 
>> On Wed, Apr 11, 2012 at 5:12 AM, Zachary Pincus <zac...@ya...> wrote:
>>> 1. Keyboard input always goes to the terminal. Shortcuts don't work in the standard plot windows and my custom widgets no longer catch key_press_events  (I'm not sure when this functionality broke exactly as I haven't used those widgets much recently but it worked when I developed 'em a year or two ago.)
>>> 
>>> 2. There's no icon in the cmd-tab task switcher corresponding to the figure windows. Swapping to the terminal running ipython (or the qtconsole for ipython qtconsole) does not raise the windows.
>>> 
>>> 3. Using mission control, the figures appear grouped as if they belong to an application of their own. However, when you click on them to swap to them and bring them forward from behind other windows, they raise and then immediately disappear again. I think that mission control is raising the specific window you select from the collection of figures, but then OSX is somehow immediately re-raising the previously selected app, which hides the figures again.
>> 
>> Hmm, I don't really see these issues, using a dev matplotlib, OS X 10.7.3, and a python.org python 2.7. Interesting. (This is with the 'MacOSX' backend, mind. Also note that on March 5 there was a patch to that backend to fix a few issues, so if your matplotlib checkout is before that, perhaps that's the problem?)
>> 
>> Anyhow, when I start python (or ipython), and then do "import matplotlib.pyplot as plt", nothing happens, but then "plt.figure()", for example, causes a new dock icon to appear -- a python rocket-ship thing -- that acts as an "app" that owns the figure windows. I can use this app to switch to / raise the windows from the dock or the cmd-tab switcher, and things work correctly via mission control as well.
>> 
>> The keyboard shortcuts are a bit flaky ('s' never seems to work, but I can e.g. toggle gridlines with 'g' or log-axes with 'l'), but the key-presses definitely don't go to the terminal.
>> 
>> I wonder what the difference is? Perhaps the apple-supplied python is a bit broken in this regard?
>> 
>> Zach
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second 
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Huh, bizarre. So neither of you get the little rocket-ship app icon appear when matplotlib first draws a window?
And matplotlib.rcParams['backend'] is definitely 'MacOSX'?

Hopefully someone who knows more about the OS X backend can comment here...
Zach


On Apr 11, 2012, at 2:19 PM, Chris Laumann wrote:

> I get the exact same behavior from both Enthought supplied python and Apple supplied python. I haven't tried any other pythons, but it isn't limited to the Apple one.
> 
> C
> 
> On Apr 11, 2012, at 1:58 PM, Elliot Saba wrote:
> 
>> I'm using homebrew python, which is built from source, and the latest matplotlib gotten from git://github.com/matplotlib/matplotlib.git.  (I rebuilt it ~2 minutes ago)
>> 
>> Perhaps there's some kind of environment difference?
>> -E
>> 
>> On Wed, Apr 11, 2012 at 5:12 AM, Zachary Pincus <zac...@ya...> wrote:
>>> 1. Keyboard input always goes to the terminal. Shortcuts don't work in the standard plot windows and my custom widgets no longer catch key_press_events  (I'm not sure when this functionality broke exactly as I haven't used those widgets much recently but it worked when I developed 'em a year or two ago.)
>>> 
>>> 2. There's no icon in the cmd-tab task switcher corresponding to the figure windows. Swapping to the terminal running ipython (or the qtconsole for ipython qtconsole) does not raise the windows.
>>> 
>>> 3. Using mission control, the figures appear grouped as if they belong to an application of their own. However, when you click on them to swap to them and bring them forward from behind other windows, they raise and then immediately disappear again. I think that mission control is raising the specific window you select from the collection of figures, but then OSX is somehow immediately re-raising the previously selected app, which hides the figures again.
>> 
>> Hmm, I don't really see these issues, using a dev matplotlib, OS X 10.7.3, and a python.org python 2.7. Interesting. (This is with the 'MacOSX' backend, mind. Also note that on March 5 there was a patch to that backend to fix a few issues, so if your matplotlib checkout is before that, perhaps that's the problem?)
>> 
>> Anyhow, when I start python (or ipython), and then do "import matplotlib.pyplot as plt", nothing happens, but then "plt.figure()", for example, causes a new dock icon to appear -- a python rocket-ship thing -- that acts as an "app" that owns the figure windows. I can use this app to switch to / raise the windows from the dock or the cmd-tab switcher, and things work correctly via mission control as well.
>> 
>> The keyboard shortcuts are a bit flaky ('s' never seems to work, but I can e.g. toggle gridlines with 'g' or log-axes with 'l'), but the key-presses definitely don't go to the terminal.
>> 
>> I wonder what the difference is? Perhaps the apple-supplied python is a bit broken in this regard?
>> 
>> Zach
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second 
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

I get the exact same behavior from both Enthought supplied python and Apple supplied python. I haven't tried any other pythons, but it isn't limited to the Apple one.

C

On Apr 11, 2012, at 1:58 PM, Elliot Saba wrote:

> I'm using homebrew python, which is built from source, and the latest matplotlib gotten from git://github.com/matplotlib/matplotlib.git.  (I rebuilt it ~2 minutes ago)
> 
> Perhaps there's some kind of environment difference?
> -E
> 
> On Wed, Apr 11, 2012 at 5:12 AM, Zachary Pincus <zac...@ya...> wrote:
> > 1. Keyboard input always goes to the terminal. Shortcuts don't work in the standard plot windows and my custom widgets no longer catch key_press_events  (I'm not sure when this functionality broke exactly as I haven't used those widgets much recently but it worked when I developed 'em a year or two ago.)
> >
> > 2. There's no icon in the cmd-tab task switcher corresponding to the figure windows. Swapping to the terminal running ipython (or the qtconsole for ipython qtconsole) does not raise the windows.
> >
> > 3. Using mission control, the figures appear grouped as if they belong to an application of their own. However, when you click on them to swap to them and bring them forward from behind other windows, they raise and then immediately disappear again. I think that mission control is raising the specific window you select from the collection of figures, but then OSX is somehow immediately re-raising the previously selected app, which hides the figures again.
> 
> Hmm, I don't really see these issues, using a dev matplotlib, OS X 10.7.3, and a python.org python 2.7. Interesting. (This is with the 'MacOSX' backend, mind. Also note that on March 5 there was a patch to that backend to fix a few issues, so if your matplotlib checkout is before that, perhaps that's the problem?)
> 
> Anyhow, when I start python (or ipython), and then do "import matplotlib.pyplot as plt", nothing happens, but then "plt.figure()", for example, causes a new dock icon to appear -- a python rocket-ship thing -- that acts as an "app" that owns the figure windows. I can use this app to switch to / raise the windows from the dock or the cmd-tab switcher, and things work correctly via mission control as well.
> 
> The keyboard shortcuts are a bit flaky ('s' never seems to work, but I can e.g. toggle gridlines with 'g' or log-axes with 'l'), but the key-presses definitely don't go to the terminal.
> 
> I wonder what the difference is? Perhaps the apple-supplied python is a bit broken in this regard?
> 
> Zach
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second 
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I'm using homebrew python, which is built from source, and the latest
matplotlib gotten from git://github.com/matplotlib/matplotlib.git.  (I
rebuilt it ~2 minutes ago)

Perhaps there's some kind of environment difference?
-E

On Wed, Apr 11, 2012 at 5:12 AM, Zachary Pincus <zac...@ya...>wrote:

> > 1. Keyboard input always goes to the terminal. Shortcuts don't work in
> the standard plot windows and my custom widgets no longer catch
> key_press_events  (I'm not sure when this functionality broke exactly as I
> haven't used those widgets much recently but it worked when I developed 'em
> a year or two ago.)
> >
> > 2. There's no icon in the cmd-tab task switcher corresponding to the
> figure windows. Swapping to the terminal running ipython (or the qtconsole
> for ipython qtconsole) does not raise the windows.
> >
> > 3. Using mission control, the figures appear grouped as if they belong
> to an application of their own. However, when you click on them to swap to
> them and bring them forward from behind other windows, they raise and then
> immediately disappear again. I think that mission control is raising the
> specific window you select from the collection of figures, but then OSX is
> somehow immediately re-raising the previously selected app, which hides the
> figures again.
>
> Hmm, I don't really see these issues, using a dev matplotlib, OS X 10.7.3,
> and a python.org python 2.7. Interesting. (This is with the 'MacOSX'
> backend, mind. Also note that on March 5 there was a patch to that backend
> to fix a few issues, so if your matplotlib checkout is before that, perhaps
> that's the problem?)
>
> Anyhow, when I start python (or ipython), and then do "import
> matplotlib.pyplot as plt", nothing happens, but then "plt.figure()", for
> example, causes a new dock icon to appear -- a python rocket-ship thing --
> that acts as an "app" that owns the figure windows. I can use this app to
> switch to / raise the windows from the dock or the cmd-tab switcher, and
> things work correctly via mission control as well.
>
> The keyboard shortcuts are a bit flaky ('s' never seems to work, but I can
> e.g. toggle gridlines with 'g' or log-axes with 'l'), but the key-presses
> definitely don't go to the terminal.
>
> I wonder what the difference is? Perhaps the apple-supplied python is a
> bit broken in this regard?
>
> Zach
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

> 1. Keyboard input always goes to the terminal. Shortcuts don't work in the standard plot windows and my custom widgets no longer catch key_press_events  (I'm not sure when this functionality broke exactly as I haven't used those widgets much recently but it worked when I developed 'em a year or two ago.)
> 
> 2. There's no icon in the cmd-tab task switcher corresponding to the figure windows. Swapping to the terminal running ipython (or the qtconsole for ipython qtconsole) does not raise the windows.
> 
> 3. Using mission control, the figures appear grouped as if they belong to an application of their own. However, when you click on them to swap to them and bring them forward from behind other windows, they raise and then immediately disappear again. I think that mission control is raising the specific window you select from the collection of figures, but then OSX is somehow immediately re-raising the previously selected app, which hides the figures again.

Hmm, I don't really see these issues, using a dev matplotlib, OS X 10.7.3, and a python.org python 2.7. Interesting. (This is with the 'MacOSX' backend, mind. Also note that on March 5 there was a patch to that backend to fix a few issues, so if your matplotlib checkout is before that, perhaps that's the problem?)

Anyhow, when I start python (or ipython), and then do "import matplotlib.pyplot as plt", nothing happens, but then "plt.figure()", for example, causes a new dock icon to appear -- a python rocket-ship thing -- that acts as an "app" that owns the figure windows. I can use this app to switch to / raise the windows from the dock or the cmd-tab switcher, and things work correctly via mission control as well.

The keyboard shortcuts are a bit flaky ('s' never seems to work, but I can e.g. toggle gridlines with 'g' or log-axes with 'l'), but the key-presses definitely don't go to the terminal.

I wonder what the difference is? Perhaps the apple-supplied python is a bit broken in this regard?

Zach

I can confirm all three of these issues. Having never used matplotlib
outside of OSX Lion, I thought this was standard for MPL, I'm glad to hear
it's not, but I agree that these are very important issues to be addressed.
-E

On Tue, Apr 10, 2012 at 7:12 PM, Chris Laumann <cla...@ph...
> wrote:

> Hi all-
>
> I've been running into this issue for the last few months and at first
> thought it was Enthought specific but now have confirmed it on a clean
> (virtualenv) install of Fonnesbeck's superpack using built in Apple python
> and a dev matplotlib on Lion.
>
> With the OSX backend, figures clearly have focus issues:
>
> 1. Keyboard input always goes to the terminal. Shortcuts don't work in the
> standard plot windows and my custom widgets no longer catch
> key_press_events  (I'm not sure when this functionality broke exactly as I
> haven't used those widgets much recently but it worked when I developed 'em
> a year or two ago.)
>
> 2. There's no icon in the cmd-tab task switcher corresponding to the
> figure windows. Swapping to the terminal running ipython (or the qtconsole
> for ipython qtconsole) does not raise the windows.
>
> 3. Using mission control, the figures appear grouped as if they belong to
> an application of their own. However, when you click on them to swap to
> them and bring them forward from behind other windows, they raise and then
> immediately disappear again. I think that mission control is raising the
> specific window you select from the collection of figures, but then OSX is
> somehow immediately re-raising the previously selected app, which hides the
> figures again.
>
> Just to check its not IPython's fault, I also checked running a bare
> python, import all from pylab and showed a (blocking) figure -- exact same
> behavior.
>
> Is this a known bug? It's quite annoying not to be able to switch focus to
> a plot window.
>
> Best, Chris
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 11/04/12 07:34, Paul Hobson wrote:
> Ben
> Does "ax.set_xlim([0,50])" do what you want it to do?
>
> -paul

hi paul,

i finally worked it out, and should have replied to myself:

ax.set_xticks(np.arange(0,100,20))

for me it seemed to work.

ben.

Hi all-

I've been running into this issue for the last few months and at first thought it was Enthought specific but now have confirmed it on a clean (virtualenv) install of Fonnesbeck's superpack using built in Apple python and a dev matplotlib on Lion.

With the OSX backend, figures clearly have focus issues:

1. Keyboard input always goes to the terminal. Shortcuts don't work in the standard plot windows and my custom widgets no longer catch key_press_events  (I'm not sure when this functionality broke exactly as I haven't used those widgets much recently but it worked when I developed 'em a year or two ago.)

2. There's no icon in the cmd-tab task switcher corresponding to the figure windows. Swapping to the terminal running ipython (or the qtconsole for ipython qtconsole) does not raise the windows.

3. Using mission control, the figures appear grouped as if they belong to an application of their own. However, when you click on them to swap to them and bring them forward from behind other windows, they raise and then immediately disappear again. I think that mission control is raising the specific window you select from the collection of figures, but then OSX is somehow immediately re-raising the previously selected app, which hides the figures again.

Just to check its not IPython's fault, I also checked running a bare python, import all from pylab and showed a (blocking) figure -- exact same behavior.

Is this a known bug? It's quite annoying not to be able to switch focus to a plot window.

Best, Chris

Ben
Does "ax.set_xlim([0,50])" do what you want it to do?

-paul

On Tue, Apr 3, 2012 at 5:57 PM, Ben Harrison
<ben...@li...> wrote:
> I create my figure in my (non-interactive) script like so:
>
> import matplotlib.pyplot as plt
> fig = plt.figure()
> ax = fig.add_subplot(111)
> ax.plot(...)
>
> Then I want to set the spacing of y grid to 50 units (axis units). Do I
> need a method of the matplotlib.axis.Axis, or matplotlib.axes.Axes (or
> are these the same??), or something else?
>
> Ben.
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Dear all,

I found that the numpoints in legend function for scatter plot is not
working?

import matplotlib as mat
import matplotlib.pyplot as plt
In [59]: mat.__version__
Out[59]: '1.1.0'

#ordinary plot working
fig=plt.figure()
ax=fig.add_subplot(111)
ax.plot(np.arange(10),'ro',label='tst')
ax.legend(numpoints=1)
plt.show()

#but not scatter plot
fig=plt.figure()
ax=fig.add_subplot(111)
ax.scatter(np.arange(10),np.arange(10),marker='o',label='tst')
ax.legend(numpoints=1)
plt.show()

cheers,

chao

-- 
View this message in context: http://old.nabble.com/numpoints-in-legend%28%29-function-for-scatter-plot-is-not-working-in-matplotlib-1.1.0--tp33662785p33662785.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Dear all,

I found that the numpoints in legend function for scatter plot is not
working?

import matplotlib as mat
import matplotlib.pyplot as plt
In [59]: mat.__version__
Out[59]: '1.1.0'

#ordinary plot working
fig=plt.figure()
ax=fig.add_subplot(111)
ax.plot(np.arange(10),'ro',label='tst')
ax.legend(numpoints=1)
plt.show()

#but not scatter plot
fig=plt.figure()
ax=fig.add_subplot(111)
ax.scatter(np.arange(10),np.arange(10),marker='o',label='tst')
ax.legend(numpoints=1)
plt.show()

cheers,

chao

-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
************************************************************************************

Dear all,

I use matplotlib 1.1.0.

import matplotlib.pyplot as plt
plt.plot(np.arange(10),'ro',mec='none')

when I use plt.show(),

there is only blank frame with axis not no points.

but plt.plot(np.arange(10),'ro') will give good plot with read filled
circles and black edges.

plt.scatter(np.arange(10),np.arange(10),c='r',marker='o',edgecolor='none')
is working fine.

but I really think plt.plot is a very good and easy function if you don't
make complex scatter points. and the circles look much nicer than that
produced by plt.scatter (thought I don't know why
as they use the same symble....)

does anyone else have found the same ?

thanks to all,

Chao
-- 
View this message in context: http://old.nabble.com/markeredgecolor-%28mec%29-in-the-plot-function-not-working--tp33662659p33662659.html
Sent from the matplotlib - users mailing list archive at Nabble.com.