matplotlib-users Mailing List for matplotlib

Take a look at matplotlib.cbook.get_sample_data.

That said, I don't think an _axes_ object should have such a function and
axes3d.get_test_data() should be removed.

Tom

On Thu Nov 06 2014 at 11:40:18 AM Adam Hughes <hug...@gm...>
wrote:

> Hi,
>
> I recently noticed the method:
>
>     axes3d.get_test_data()
>
> I was curious if other test/sample data is available somewhere in
> matplotlib, for demo purposes?  Or if this is the only sample dataset in
> the library?  Not just for 3dplots but for any plot type...  Sorry if I'm
> overlooking the obvious...
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

It works. Thanks a lot for explanation, Ben.

Stepan

On Fri, Nov 7, 2014 at 6:37 PM, Benjamin Root <ben...@ou...> wrote:

> Figured it out! The instance of Test() isn't being retained anywhere, so
> when it goes out of scope, the garbage collector eventually gets it. The
> fact that it works in py3k is likely a coincidence as the garbage collector
> would eventually have cleaned it up at some point. I don't know the
> scoping/garbage collection rules for lambdas, so I am guessing that they
> persist as they are part of the code as opposed to a de-reference-able (is
> that even a word?). Just save the instance of Test as a member variable of
> App, and you should be good to go!
>
> Ben Root
>
> On Fri, Nov 7, 2014 at 10:05 AM, rouckas <ste...@gm...> wrote:
>
>> Thanks for the tip. However, subclassing from object didn't help.
>>
>>
>>
>> --
>> View this message in context:
>> http://matplotlib.1069221.n5.nabble.com/Problem-with-event-handling-in-matplotlib-in-tkinter-tp44302p44315.html
>> Sent from the matplotlib - users mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
>

Sorry I'm lost in the discussion.
What is the relation between the weak references in callback registry and
moving stuff to the figure manager?

Federico
On 7 Nov 2014 14:13, "Thomas Caswell" <tca...@gm...> wrote:

> I am also beginning to like the idea of hanging all of these things off of
> FigureManager objects.  We have them around, but they are really only used
> in pyplot (which is a shame) and seems a natural place to put all of these
> aggregation type objects (list of animations, the toolbar stuff, the
> navigation stuff, the blit-manager object I want to pull in from
> scikit-image, etc).
>
> @Federico, tell me if I am being dumb about this.
>
> Tom
>
> On Fri Nov 07 2014 at 2:05:29 PM Thomas Caswell <tca...@gm...>
> wrote:
>
>> The old-style classes are because mpl pre-dates new-style classes.  On
>> master all classes now inherit from object (as of about 3 weeks ago
>> https://github.com/matplotlib/matplotlib/pull/3662)
>>
>>
>>
>> On Fri Nov 07 2014 at 2:02:15 PM Brendan Barnwell <bre...@br...>
>> wrote:
>>
>>> On 2014-11-07 09:37, Benjamin Root wrote:
>>> > Figured it out! The instance of Test() isn't being retained anywhere,
>>> so
>>> > when it goes out of scope, the garbage collector eventually gets it.
>>> The
>>> > fact that it works in py3k is likely a coincidence as the garbage
>>> > collector would eventually have cleaned it up at some point. I don't
>>> > know the scoping/garbage collection rules for lambdas, so I am guessing
>>> > that they persist as they are part of the code as opposed to a
>>> > de-reference-able (is that even a word?). Just save the instance of
>>> Test
>>> > as a member variable of App, and you should be good to go!
>>>
>>>         This note in cbook.py (which handles the callback registry)
>>> explains
>>> it. . . sort of:
>>>
>>> In practice, one should always disconnect all callbacks when they
>>> are no longer needed to avoid dangling references (and thus memory
>>> leaks).  However, real code in matplotlib rarely does so, and due
>>> to its design, it is rather difficult to place this kind of code.
>>> To get around this, and prevent this class of memory leaks, we
>>> instead store weak references to bound methods only, so when the
>>> destination object needs to die, the CallbackRegistry won't keep
>>> it alive.  The Python stdlib weakref module can not create weak
>>> references to bound methods directly, so we need to create a proxy
>>> object to handle weak references to bound methods (or regular free
>>> functions).  This technique was shared by Peter Parente on his
>>> `"Mindtrove" blog
>>> <http://mindtrove.info/articles/python-weak-references/>`_.
>>>
>>>         Definitely a hidden trap!
>>>
>>>         Also, speaking of the dangers of classes not inheriting from
>>> object, I
>>> noticed that CallbackRegistry in cbook.py is also an old-style class
>>> (doesn't inherit from object).  I then did a search and found numerous
>>> old-style classes throughout MPL.  Is there any reason for this?
>>>
>>> --
>>> Brendan Barnwell
>>> "Do not follow where the path may lead.  Go, instead, where there is no
>>> path, and leave a trail."
>>>     --author unknown
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>

I am also beginning to like the idea of hanging all of these things off of
FigureManager objects.  We have them around, but they are really only used
in pyplot (which is a shame) and seems a natural place to put all of these
aggregation type objects (list of animations, the toolbar stuff, the
navigation stuff, the blit-manager object I want to pull in from
scikit-image, etc).

@Federico, tell me if I am being dumb about this.

Tom

On Fri Nov 07 2014 at 2:05:29 PM Thomas Caswell <tca...@gm...> wrote:

> The old-style classes are because mpl pre-dates new-style classes.  On
> master all classes now inherit from object (as of about 3 weeks ago
> https://github.com/matplotlib/matplotlib/pull/3662)
>
>
>
> On Fri Nov 07 2014 at 2:02:15 PM Brendan Barnwell <bre...@br...>
> wrote:
>
>> On 2014-11-07 09:37, Benjamin Root wrote:
>> > Figured it out! The instance of Test() isn't being retained anywhere, so
>> > when it goes out of scope, the garbage collector eventually gets it. The
>> > fact that it works in py3k is likely a coincidence as the garbage
>> > collector would eventually have cleaned it up at some point. I don't
>> > know the scoping/garbage collection rules for lambdas, so I am guessing
>> > that they persist as they are part of the code as opposed to a
>> > de-reference-able (is that even a word?). Just save the instance of Test
>> > as a member variable of App, and you should be good to go!
>>
>>         This note in cbook.py (which handles the callback registry)
>> explains
>> it. . . sort of:
>>
>> In practice, one should always disconnect all callbacks when they
>> are no longer needed to avoid dangling references (and thus memory
>> leaks).  However, real code in matplotlib rarely does so, and due
>> to its design, it is rather difficult to place this kind of code.
>> To get around this, and prevent this class of memory leaks, we
>> instead store weak references to bound methods only, so when the
>> destination object needs to die, the CallbackRegistry won't keep
>> it alive.  The Python stdlib weakref module can not create weak
>> references to bound methods directly, so we need to create a proxy
>> object to handle weak references to bound methods (or regular free
>> functions).  This technique was shared by Peter Parente on his
>> `"Mindtrove" blog
>> <http://mindtrove.info/articles/python-weak-references/>`_.
>>
>>         Definitely a hidden trap!
>>
>>         Also, speaking of the dangers of classes not inheriting from
>> object, I
>> noticed that CallbackRegistry in cbook.py is also an old-style class
>> (doesn't inherit from object).  I then did a search and found numerous
>> old-style classes throughout MPL.  Is there any reason for this?
>>
>> --
>> Brendan Barnwell
>> "Do not follow where the path may lead.  Go, instead, where there is no
>> path, and leave a trail."
>>     --author unknown
>>
>> ------------------------------------------------------------
>> ------------------
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>

The old-style classes are because mpl pre-dates new-style classes.  On
master all classes now inherit from object (as of about 3 weeks ago
https://github.com/matplotlib/matplotlib/pull/3662)



On Fri Nov 07 2014 at 2:02:15 PM Brendan Barnwell <bre...@br...>
wrote:

> On 2014-11-07 09:37, Benjamin Root wrote:
> > Figured it out! The instance of Test() isn't being retained anywhere, so
> > when it goes out of scope, the garbage collector eventually gets it. The
> > fact that it works in py3k is likely a coincidence as the garbage
> > collector would eventually have cleaned it up at some point. I don't
> > know the scoping/garbage collection rules for lambdas, so I am guessing
> > that they persist as they are part of the code as opposed to a
> > de-reference-able (is that even a word?). Just save the instance of Test
> > as a member variable of App, and you should be good to go!
>
>         This note in cbook.py (which handles the callback registry)
> explains
> it. . . sort of:
>
> In practice, one should always disconnect all callbacks when they
> are no longer needed to avoid dangling references (and thus memory
> leaks).  However, real code in matplotlib rarely does so, and due
> to its design, it is rather difficult to place this kind of code.
> To get around this, and prevent this class of memory leaks, we
> instead store weak references to bound methods only, so when the
> destination object needs to die, the CallbackRegistry won't keep
> it alive.  The Python stdlib weakref module can not create weak
> references to bound methods directly, so we need to create a proxy
> object to handle weak references to bound methods (or regular free
> functions).  This technique was shared by Peter Parente on his
> `"Mindtrove" blog
> <http://mindtrove.info/articles/python-weak-references/>`_.
>
>         Definitely a hidden trap!
>
>         Also, speaking of the dangers of classes not inheriting from
> object, I
> noticed that CallbackRegistry in cbook.py is also an old-style class
> (doesn't inherit from object).  I then did a search and found numerous
> old-style classes throughout MPL.  Is there any reason for this?
>
> --
> Brendan Barnwell
> "Do not follow where the path may lead.  Go, instead, where there is no
> path, and leave a trail."
>     --author unknown
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

There have been some discussion of adding an fig.animations list (a la
ax.images, ax.artists), and have a fig.add_animation() method. We could
then update the animation code to add itself to the given figure to make
this work for all existing code. Maybe it would be a nice tie-in with the
updates to the navigation toolbar (automatically adding useful buttons for
starting/pausing animations, etc)?

On Fri, Nov 7, 2014 at 1:35 PM, Thomas Caswell <tca...@gm...> wrote:

> This came up regrading sliders a while ago:
> https://github.com/matplotlib/matplotlib/issues/3105 and is one of the
> persistent gotchas with animation code.
>
> Tom
>
> On Fri Nov 07 2014 at 12:38:28 PM Benjamin Root <ben...@ou...> wrote:
>
>> Figured it out! The instance of Test() isn't being retained anywhere, so
>> when it goes out of scope, the garbage collector eventually gets it. The
>> fact that it works in py3k is likely a coincidence as the garbage collector
>> would eventually have cleaned it up at some point. I don't know the
>> scoping/garbage collection rules for lambdas, so I am guessing that they
>> persist as they are part of the code as opposed to a de-reference-able (is
>> that even a word?). Just save the instance of Test as a member variable of
>> App, and you should be good to go!
>>
>> Ben Root
>>
>> On Fri, Nov 7, 2014 at 10:05 AM, rouckas <ste...@gm...> wrote:
>>
>>> Thanks for the tip. However, subclassing from object didn't help.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://matplotlib.1069221.n5.nabble.com/Problem-with-event-handling-in-matplotlib-in-tkinter-tp44302p44315.html
>>> Sent from the matplotlib - users mailing list archive at Nabble.com.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>

On 2014-11-07 09:37, Benjamin Root wrote:
> Figured it out! The instance of Test() isn't being retained anywhere, so
> when it goes out of scope, the garbage collector eventually gets it. The
> fact that it works in py3k is likely a coincidence as the garbage
> collector would eventually have cleaned it up at some point. I don't
> know the scoping/garbage collection rules for lambdas, so I am guessing
> that they persist as they are part of the code as opposed to a
> de-reference-able (is that even a word?). Just save the instance of Test
> as a member variable of App, and you should be good to go!

	This note in cbook.py (which handles the callback registry) explains 
it. . . sort of:

In practice, one should always disconnect all callbacks when they
are no longer needed to avoid dangling references (and thus memory
leaks).  However, real code in matplotlib rarely does so, and due
to its design, it is rather difficult to place this kind of code.
To get around this, and prevent this class of memory leaks, we
instead store weak references to bound methods only, so when the
destination object needs to die, the CallbackRegistry won't keep
it alive.  The Python stdlib weakref module can not create weak
references to bound methods directly, so we need to create a proxy
object to handle weak references to bound methods (or regular free
functions).  This technique was shared by Peter Parente on his
`"Mindtrove" blog
<http://mindtrove.info/articles/python-weak-references/>`_.

	Definitely a hidden trap!

	Also, speaking of the dangers of classes not inheriting from object, I 
noticed that CallbackRegistry in cbook.py is also an old-style class 
(doesn't inherit from object).  I then did a search and found numerous 
old-style classes throughout MPL.  Is there any reason for this?

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."
    --author unknown

This came up regrading sliders a while ago:
https://github.com/matplotlib/matplotlib/issues/3105 and is one of the
persistent gotchas with animation code.

Tom

On Fri Nov 07 2014 at 12:38:28 PM Benjamin Root <ben...@ou...> wrote:

> Figured it out! The instance of Test() isn't being retained anywhere, so
> when it goes out of scope, the garbage collector eventually gets it. The
> fact that it works in py3k is likely a coincidence as the garbage collector
> would eventually have cleaned it up at some point. I don't know the
> scoping/garbage collection rules for lambdas, so I am guessing that they
> persist as they are part of the code as opposed to a de-reference-able (is
> that even a word?). Just save the instance of Test as a member variable of
> App, and you should be good to go!
>
> Ben Root
>
> On Fri, Nov 7, 2014 at 10:05 AM, rouckas <ste...@gm...> wrote:
>
>> Thanks for the tip. However, subclassing from object didn't help.
>>
>>
>>
>> --
>> View this message in context:
>> http://matplotlib.1069221.n5.nabble.com/Problem-with-event-handling-in-matplotlib-in-tkinter-tp44302p44315.html
>> Sent from the matplotlib - users mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I am unfamiliar with zypper (seems to be a package manager of some sort).
Does it build the binaries from source on your system, or does it just
install binaries from a repository? Was there an existing install of
matplotlib?

Cheers!
Ben Root

On Thu, Nov 6, 2014 at 4:04 PM, ahtos <sy...@md...> wrote:

> ImportError:
> /usr/lib64/python2.6/site-packages/matplotlib/backends/_backend_agg.so:
> undefined symbol: MPL_matplotlib__path_ARRAY_API
>
> SUSE Linux Enterprise Server 11 (x86_64)
> VERSION = 11
> PATCHLEVEL = 3
>
> Python 2.6.9
> GCC 4.3.4
> numpy 1.8.0
>
>
> installed through zypper
>
> thanks,
>
>
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/error-import-matplotlib-pyplot-tp44297.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Figured it out! The instance of Test() isn't being retained anywhere, so
when it goes out of scope, the garbage collector eventually gets it. The
fact that it works in py3k is likely a coincidence as the garbage collector
would eventually have cleaned it up at some point. I don't know the
scoping/garbage collection rules for lambdas, so I am guessing that they
persist as they are part of the code as opposed to a de-reference-able (is
that even a word?). Just save the instance of Test as a member variable of
App, and you should be good to go!

Ben Root

On Fri, Nov 7, 2014 at 10:05 AM, rouckas <ste...@gm...> wrote:

> Thanks for the tip. However, subclassing from object didn't help.
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/Problem-with-event-handling-in-matplotlib-in-tkinter-tp44302p44315.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

The style module (extracted from mpltools) is now part of the library and
was one of the major features added in the 1.4 series.

See http://matplotlib.org/users/style_sheets.html

Tom

On Fri Nov 07 2014 at 11:05:58 AM Adam Hughes <hug...@gm...>
wrote:

> I use a config file in ipython notebooks that sets some parameters of the
> ipython notebook and then sets the matplotlib defaults.
>
>
> http://nbviewer.ipython.org/github/hugadams/pyuvvis/blob/master/examples/Notebooks/NBCONFIG.ipynb
>
> Then I use in all subsequent analysis in the ipython notebook:
>
>
> http://nbviewer.ipython.org/urls/raw.github.com/hugadams/pyuvvis/master/examples/Notebooks/basic_units.ipynb
>
> On Fri, Nov 7, 2014 at 10:15 AM, Sebastian Berg <
> seb...@si...> wrote:
>
>> Hey,
>>
>> just something I was wondering about today. I commonly want to change
>> certain things about my plots. For example I like a serif/larger fonts,
>> and everyone knows that "jet" is an awful default colour map almost
>> always...
>>
>> It could be neat to have some more "default" rc's or so that can be
>> loaded easily. I mean I could just create one for myself, but having
>> some examples of what can be done and being able to switch that could be
>> neat. Such as some defaults that are better for printing, maybe in
>> matplotlib or really just on a website which shows some example plot for
>> uploaded RCs.
>>
>> Anyway, just rambling :), I am not planning to really think about it
>> much. And maybe some things even exist and I am not aware of it.
>>
>> Regards,
>>
>> Sebastian
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Fr, 2014-11-07 at 16:15 +0100, Sebastian Berg wrote:
> Hey,
> 
> just something I was wondering about today. I commonly want to change
> certain things about my plots. For example I like a serif/larger fonts,
> and everyone knows that "jet" is an awful default colour map almost
> always...
> 
> It could be neat to have some more "default" rc's or so that can be
> loaded easily. I mean I could just create one for myself, but having
> some examples of what can be done and being able to switch that could be
> neat. Such as some defaults that are better for printing, maybe in
> matplotlib or really just on a website which shows some example plot for
> uploaded RCs.
> 
> Anyway, just rambling :), I am not planning to really think about it
> much. And maybe some things even exist and I am not aware of it.
> 

Nevermind, seems like we got matpltolib.style in 1.4, that is cool. Now
all I could hope for is for some more styles ;). 

- Sebastian


> Regards,
> 
> Sebastian
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I use a config file in ipython notebooks that sets some parameters of the
ipython notebook and then sets the matplotlib defaults.

http://nbviewer.ipython.org/github/hugadams/pyuvvis/blob/master/examples/Notebooks/NBCONFIG.ipynb

Then I use in all subsequent analysis in the ipython notebook:

http://nbviewer.ipython.org/urls/raw.github.com/hugadams/pyuvvis/master/examples/Notebooks/basic_units.ipynb

On Fri, Nov 7, 2014 at 10:15 AM, Sebastian Berg <seb...@si...>
wrote:

> Hey,
>
> just something I was wondering about today. I commonly want to change
> certain things about my plots. For example I like a serif/larger fonts,
> and everyone knows that "jet" is an awful default colour map almost
> always...
>
> It could be neat to have some more "default" rc's or so that can be
> loaded easily. I mean I could just create one for myself, but having
> some examples of what can be done and being able to switch that could be
> neat. Such as some defaults that are better for printing, maybe in
> matplotlib or really just on a website which shows some example plot for
> uploaded RCs.
>
> Anyway, just rambling :), I am not planning to really think about it
> much. And maybe some things even exist and I am not aware of it.
>
> Regards,
>
> Sebastian
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hi Sebastian,

If you want to set the defaults only once and use them forever, there is
the matplotlibrc file (http://matplotlib.org/users/customizing.html)

If you want to easily change the defaults according to the context of the
plot mpltools by Tony S. Yu can help you (
https://github.com/tonysyu/mpltools)

Cheers,
Fra

2014-11-07 16:15 GMT+01:00 Sebastian Berg <seb...@si...>:

> Hey,
>
> just something I was wondering about today. I commonly want to change
> certain things about my plots. For example I like a serif/larger fonts,
> and everyone knows that "jet" is an awful default colour map almost
> always...
>
> It could be neat to have some more "default" rc's or so that can be
> loaded easily. I mean I could just create one for myself, but having
> some examples of what can be done and being able to switch that could be
> neat. Such as some defaults that are better for printing, maybe in
> matplotlib or really just on a website which shows some example plot for
> uploaded RCs.
>
> Anyway, just rambling :), I am not planning to really think about it
> much. And maybe some things even exist and I am not aware of it.
>
> Regards,
>
> Sebastian
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

I agree that it would be useful, but basemap doesn't support EPSG codes, so
this isn't fully possible in general.

On a side note, if you're ever just wanting to transform coordinates,
pyproj supports generic proj4 strings.  (e.g. "proj =
pyproj.Proj(your_proj4_string)")

It might be possible to initialize a projection in Cartopy from a generic
pyproj projection... I'm not sure, though.

At any rate, that doesn't answer your question at all, but consider it food
for thought.
Cheers,
-Joe

On Fri, Nov 7, 2014 at 7:16 AM, Knut-Frode Dagestad <
knu...@ho...> wrote:

>  As an example, say I have a proj4 string defining a spatial reference
> system:
> p4 = '+lon_0=0.0 +lat_ts=60.0 +R=6370997.0 +proj=stere +x_0=-0.0 +units=m
> +y_0=4327039.11059 +lat_0=90.0'
>
> Then one can construct a Basemap from this as:
> map = Basemap(projection='stere', lon_0=0., lat_0=90, lat_ts=60,
>         llcrnrlat=50, urcrnrlat=70, llcrnrlon=0, urcrnrlon=20)
>
>
> I could make a function to construct Basemap arguments from any user
> specified proj4 string (which is out of control of my application). But
> that function would probably be long and contain a lot of
> projection-specific if-then-switches. Copying proj4 arguments directly does
> not work, e.g. if passing "x_0=0" Basemap complains that x_0 is an
> unexpected argument.
> The problem of making a long parser is not that this is tedious, but that
> it is error prone and unstable e.g. with respect to future upgrades of
> Basemap or proj4 libraries.
>
> So as Basemap obviously does have an algorithm to create a proj4 string
> from its input arguments, I was hoping the reverse algorithm would also be
> available somehow. E.g. it would be very useful to be able to initialise a
> Basemap with:
>
> map = Basemap(proj4=p4, llcrnrlat=50, urcrnrlat=70, llcrnrlon=0,
> urcrnrlon=20)
>
> Knut-Frode
>
>
> ------------------------------
> Date: Wed, 5 Nov 2014 09:32:16 -0800
>
>
> I think some examples would help. Which proj4 string are you looking to
> use? How are you currently constructing the map?
> -p
>
> On Wed, Nov 5, 2014 at 7:53 AM, knutfrode <knu...@ho...>
> wrote:
>
> Does anyone know if this is possible?
>
>
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/Basemap-from-proj4-string-tp43428p44290.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hey,

just something I was wondering about today. I commonly want to change
certain things about my plots. For example I like a serif/larger fonts,
and everyone knows that "jet" is an awful default colour map almost
always...

It could be neat to have some more "default" rc's or so that can be
loaded easily. I mean I could just create one for myself, but having
some examples of what can be done and being able to switch that could be
neat. Such as some defaults that are better for printing, maybe in
matplotlib or really just on a website which shows some example plot for
uploaded RCs.

Anyway, just rambling :), I am not planning to really think about it
much. And maybe some things even exist and I am not aware of it.

Regards,

Sebastian

Thanks for the tip. However, subclassing from object didn't help.



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Problem-with-event-handling-in-matplotlib-in-tkinter-tp44302p44315.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

I think it is because your Test() class is not subclassed from "object". Of
course, I have no clue why that would be an issue, but I have seen stranger
things when not subclassing from object.

On Fri, Nov 7, 2014 at 9:31 AM, rouckas <ste...@gm...> wrote:

> I have a little update on the issue: I tried it with different versions of
> python and matplotlib and it is still present in
> python 2.7.6 + matplotlib 1.4.2
>
> but it works as expected in
> python 3.4.0 + matplotlib 1.4.2
>
> Should this be reported as a bug in matplotlib 1.4.2 on python 2.7.6?
>
> BTW, I noticed that my minimal text from previous mail didn't get through
> to
> the mailing list, so I am attaching it again (modified for python 2.7)
> without formatting:
>
> from __future__ import print_function
> import sys
> if sys.version_info < (3, 0):
>     import Tkinter as tk
> else:
>     import tkinter as tk
> from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg
> import matplotlib.figure as mplfig
>
>
> class Test:
>     def on_press(self, event):
>         print("clicked2")
>
>     def connect(self, canvas):
>         self.cidpress = canvas.mpl_connect(
>                 'button_press_event', self.on_press)
>         self.cidpress = canvas.mpl_connect(
>                 'button_press_event', lambda event: print("clicked1"))
>
> class App(object):
>     def on_press(self, event):
>         print("clicked0")
>     def __init__(self, master):
>         self.fig = mplfig.Figure()
>         self.canvas = FigureCanvasTkAgg(self.fig, master=master)
>
>         dl = Test()
>         dl.connect(self.canvas)
>
>         self.cidpress = self.canvas.mpl_connect(
>                 'button_press_event', self.on_press)
>
>         self.canvas.get_tk_widget().pack()
>         self.canvas.draw()
>
> if __name__ == "__main__":
>     root = tk.Tk()
>     app = App(root)
>     tk.mainloop()
>
> this should print
> clicked2
> clicked1
> clicked0
>
> after each click on the canvas. But in python 2.7.6 it prints only
> clicked1
> clicked0
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/Problem-with-event-handling-in-matplotlib-in-tkinter-tp44302p44307.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I have a little update on the issue: I tried it with different versions of
python and matplotlib and it is still present in
python 2.7.6 + matplotlib 1.4.2

but it works as expected in
python 3.4.0 + matplotlib 1.4.2

Should this be reported as a bug in matplotlib 1.4.2 on python 2.7.6?

BTW, I noticed that my minimal text from previous mail didn't get through to
the mailing list, so I am attaching it again (modified for python 2.7)
without formatting:

from __future__ import print_function
import sys
if sys.version_info < (3, 0):
    import Tkinter as tk
else:
    import tkinter as tk
from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg
import matplotlib.figure as mplfig


class Test:
    def on_press(self, event):
        print("clicked2")

    def connect(self, canvas):
        self.cidpress = canvas.mpl_connect(
                'button_press_event', self.on_press)
        self.cidpress = canvas.mpl_connect(
                'button_press_event', lambda event: print("clicked1"))

class App(object):
    def on_press(self, event):
        print("clicked0")
    def __init__(self, master):
        self.fig = mplfig.Figure()
        self.canvas = FigureCanvasTkAgg(self.fig, master=master)

        dl = Test()
        dl.connect(self.canvas)

        self.cidpress = self.canvas.mpl_connect(
                'button_press_event', self.on_press)

        self.canvas.get_tk_widget().pack()
        self.canvas.draw()

if __name__ == "__main__":
    root = tk.Tk()
    app = App(root)
    tk.mainloop()

this should print 
clicked2
clicked1
clicked0

after each click on the canvas. But in python 2.7.6 it prints only
clicked1
clicked0



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Problem-with-event-handling-in-matplotlib-in-tkinter-tp44302p44307.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

As an example, say I have a proj4 string defining a spatial reference system:
p4 = '+lon_0=0.0 +lat_ts=60.0 +R=6370997.0 +proj=stere +x_0=-0.0 +units=m +y_0=4327039.11059 +lat_0=90.0'

Then one can construct a Basemap from this as:
map = Basemap(projection='stere', lon_0=0., lat_0=90, lat_ts=60,  
        llcrnrlat=50, urcrnrlat=70, llcrnrlon=0, urcrnrlon=20)


I could make a function to construct Basemap arguments from any user specified proj4 string (which is out of control of my application). But that function would probably be long and contain a lot of projection-specific if-then-switches. Copying proj4 arguments directly does not work, e.g. if passing "x_0=0" Basemap complains that x_0 is an unexpected argument.
The problem of making a long parser is not that this is tedious, but that it is error prone and unstable e.g. with respect to future upgrades of Basemap or proj4 libraries.

So as Basemap obviously does have an algorithm to create a proj4 string from its input arguments, I was hoping the reverse algorithm would also be available somehow. E.g. it would be very useful to be able to initialise a Basemap with:

map = Basemap(proj4=p4, llcrnrlat=50, urcrnrlat=70, llcrnrlon=0, urcrnrlon=20)

Knut-Frode


Date: Wed, 5 Nov 2014 09:32:16 -0800

I think some examples would help. Which proj4 string are you looking to use? How are you currently constructing the map?-p
On Wed, Nov 5, 2014 at 7:53 AM, knutfrode <knu...@ho...> wrote:
Does anyone know if this is possible?











--

View this message in context: http://matplotlib.1069221.n5.nabble.com/Basemap-from-proj4-string-tp43428p44290.html

Sent from the matplotlib - users mailing list archive at Nabble.com.



------------------------------------------------------------------------------

_______________________________________________

Matplotlib-users mailing list

Mat...@li...

https://lists.sourceforge.net/lists/listinfo/matplotlib-users



 		 	   		  

Dear all,

I have a problem with using certain class methods as event handlers. In the
following example:



the method Test.on_press() is never executed. Only "clicked0" and "clicked1"
is printed when I click on the canvas. When i use pure matplotlib widgets
instead of tkinter embedding, the code works as expected. Is this a
matplotlib bug or am I doing something wrong?
My software versions are:
Python 3.4.0
matplotlib.__version__ == '1.3.1'
tkinter.TkVersion == 8.6

in Ubuntu 14.04

Thanks in advance for any help,
Stepan






--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Problem-with-event-handling-in-matplotlib-in-tkinter-tp44302.html
Sent from the matplotlib - users mailing list archive at Nabble.com.