matplotlib-devel Mailing List for matplotlib (Page 5)

Hi,

(Apologies if you get this twice - I forgot which address I subscribed
to the list with)

As some of you may have seen, there's a discussion underway on the
scipy-user mailing list about developing a common name for the scipy
stack. At present, the discussion is centring on adopting the name
pylab, as it's already familiar to people using
numpy+scipy+matplotlib. If we did use that name, we'd obviously need
to co-ordinate with matplotlib to ensure that there isn't confusion
between the name Pylab and the importable module pylab.

If you want to get involved in the discussion, please head over to the
scipy-user mailing list so we keep it in one place. You can read
through the current thread:
http://article.gmane.org/gmane.comp.python.scientific.user/32487

And the previous thread it refers to:
http://article.gmane.org/gmane.comp.python.scientific.user/32448

Thanks,
Thomas

On Tue, Sep 4, 2012 at 8:33 PM, Matt Newville
<new...@ca...> wrote:

> Sorry for the delay.... I also haven't done anything about this... yet?   I
> might be more gung-ho to fold this into my wxmplot, which is fairly similar,
> but not exactly 1-to-1,  and has some name overlaps with wxmpl.   To be
> clear, I'm willing to refactor wxmplot to better accommodate  most of  the
> wxmpl interface,

Sounds like a great idea.

> What interfaces are you actually using from wxmpl?  I guess put another way:
> what do we want for a wx interface to matplotlib that's higher level than
> the standard backend.    The PlotPanel and PlotFrames look close enough to
> merge.

Those are what I use -- actually, only the PlotPanel -- I generally
want to customize the Frame.


>   The wxmpl StripCharter seems a little different from what I do with
> wxmplot, but perhaps that and the Channel class are easy enough to emulate.

Those are kind of higher-level stuff that's more suited to wxmplot, I
think -- as I don't use them, I don't care if you break the API -- but
that's just me.

> For how / where to host it, I don't much care.  Github and pypi seem easy
> enough.

I think it would be great to put it in the mpl repo as an mpl_toolkit
-- which means github, yes?


Thanks for taking this on!

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hi Carlo,

Sorry for the delay.... I also haven't done anything about this... yet?   I
might be more gung-ho to fold this into my wxmplot, which is fairly
similar, but not exactly 1-to-1,  and has some name overlaps with wxmpl.
To be clear, I'm willing to refactor wxmplot to better accommodate  most
of  the wxmpl interface, but it would take some effort, so maybe it would
be better to have some goals in mind.

What interfaces are you actually using from wxmpl?  I guess put another
way: what do we want for a wx interface to matplotlib that's higher level
than the standard backend.    The PlotPanel and PlotFrames look close
enough to merge.   The wxmpl StripCharter seems a little different from
what I do with wxmplot, but perhaps that and the Channel class are easy
enough to emulate.

For how / where to host it, I don't much care.  Github and pypi seem easy
enough.

--Matt
On Aug 30, 2012 11:22 PM, "Carlo Segre" <se...@ii...> wrote:

>
> Hi Chris:
>
> On Tue, 1 May 2012, Chris Barker wrote:
>
>  On Tue, May 1, 2012 at 9:31 AM, Benjamin Root
>>
>>  AFAIK, no, it shouldn't be a problem.  The question is where.  I suspect
>>> it
>>> would fit best as a mpl_toolkit.
>>>
>>
>> yes -- I figured that was most likely.
>>
>>  P.S. - Of course, you do realize that you are essentially making yourself
>>> the de facto maintainer of it, right?
>>>
>>
>> Well, me or Matt or Carlo -- we'll fight over that among ourselves.
>>
>
> Just a followup.  Has wxmpl been pulled into the toolkit source yet?
>
> Carlo
>
>
> --
> Carlo U. Segre -- Duchossois Leadership Professor of Physics
> Director, Center for Synchrotron Radiation Research and Instrumentation
> Illinois Institute of Technology
> Voice: 312.567.3498            Fax: 312.567.3494
> se...@ii...   http://phys.iit.edu/~segre   se...@de...

On 5 September 2012 00:32, Michael Droettboom <md...@st...> wrote:
> I wonder if there's any possibility of using that on earlier versions (I
> suspect not).

Not easily, I think. You'd have to get introspection tools like
IPython to separately check for a __signature__ attribute, and I
suspect we'd feel that the added complexity outweighs the benefits.

Thomas

On Thu, Aug 30, 2012 at 9:22 PM, Carlo Segre <se...@ii...> wrote:
> Hi Chris:
>> On Tue, May 1, 2012 at 9:31 AM, Benjamin Root
>>
>>> AFAIK, no, it shouldn't be a problem.  The question is where.  I suspect
>>> it
>>> would fit best as a mpl_toolkit.
>>
>>
>> yes -- I figured that was most likely.

> Just a followup.  Has wxmpl been pulled into the toolkit source yet?
>
> Carlo

I haven't done anything, nor have I heard that anyone else has.

Care to take it on?

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hi Eric,

I may be able to look at this over the weekend.

Best,
-Michiel.

--- On Sun, 9/2/12, Eric Firing <ef...@ha...> wrote:

> From: Eric Firing <ef...@ha...>
> Subject: backend_macosx linewidth bug
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: "matplotlib development list" <mat...@li...>
> Date: Sunday, September 2, 2012, 10:17 PM
> Michiel,
> 
> In the 4th comment on
> 
> https://github.com/matplotlib/matplotlib/issues/786
> 
> I give a little example illustrating a macosx bug: it seems
> that when drawing a path, the linewidth, which is specified
> in points, is not interpreted correctly unless the
> figure.dpi has exactly the right value.  For a high
> dpi, as in the example I gave, all lines are too thin, but
> text is still scaled correctly, and the general layout is
> correct.
> 
> Will you be able to take a look?  We are trying to get
> out a release soon, so it would be nice to have this fixed.
> 
> Thank you.
> 
> Eric
> 

Hello,

I was playing a bit with the clippedline example
(http://matplotlib.org/examples/pylab_examples/clippedline.html) and I
feel it is not working anymore.

From what I understand of the traceback I got, there may be something
evil happening after setting
>>> self._marker = 's'
in the draw method. Maybe using the self.set_marker('s') is safer

Also, by reading some archived emails from this mailing list, it seems
that the purpose of this example became pointless because line clipping
is now implemented directly in matplotlib. Am I right ?

For what it's worth, I modified the clippeline.py example to make it
just serve the purpose of dynamically changing the appearance of the
line when zoom level is changing. I called t "zoom_adaptive_line.py" :
https://gist.github.com/3607993

Would this script be an appropriate replacement for the clippedline
example ?

Best,
Pierre

On 26 August 2012 18:19, Michael Droettboom <md...@st...> wrote:
> I understand the comments about the difficulty of introspection. The
> reason it works the way it does is so that additional parameters can be
> added to the artist layer without needing to update every single
> plotting function.  A real world example of this is when hatching was
> added -- that feature only had to be added in one place and most artists
> were able to use it.  In that sense, I think this approach is very
> beautiful in terms of code maintainability and extensibility.

I'm jumping into this conversation a bit late, but from Python 3.3 it
will be possible to set a __signature__ attribute on a function, using
a Signature object which can be programmatically generated. So it
should be possible, with a bit of legwork, to introspect pass-through
parameters without having to manually declare them at the highest
level.

The details are here:
http://www.python.org/dev/peps/pep-0362/

Thanks,
Thomas

Michiel,

In the 4th comment on

https://github.com/matplotlib/matplotlib/issues/786

I give a little example illustrating a macosx bug: it seems that when 
drawing a path, the linewidth, which is specified in points, is not 
interpreted correctly unless the figure.dpi has exactly the right value. 
  For a high dpi, as in the example I gave, all lines are too thin, but 
text is still scaled correctly, and the general layout is correct.

Will you be able to take a look?  We are trying to get out a release 
soon, so it would be nice to have this fixed.

Thank you.

Eric

Okay, here is the pull request

https://github.com/matplotlib/matplotlib/pull/1185

and the diff

https://github.com/mwelter/matplotlib/compare/master...svg-rasterize-resolution-fix


cheers
Michael