matplotlib-devel Mailing List for matplotlib (Page 12)

On Mon, Aug 3, 2009 at 2:40 PM, Eric Firing<ef...@ha...> wrote:
> John Hunter wrote:
>>
>> On Mon, Aug 3, 2009 at 2:15 PM, John Hunter<jd...@gm...> wrote:
>>
>>> This may have been Eric's change to clean up the pylab imports -- all
>>> the mlab imports come before the pylab imports.  Was this intentional?
>>>  My guess is not, since np.loadtxt is the replacement for pylab.load.
>>> I prefer to do what we are currently doing, which is issue the
>>> deprecation warning, but I wanted to at least find out if this change
>>> was intentional (I noticed it because it broke
>>> docs/pyplot/plotmap.py), which tries to load some basemap data:
>>
>> Correction, I had confused myself for a minute thinking numpy.load was
>> the old numpy.load which handled plain text files, ie what became
>> loadtxt.  np.load and np.save are too important as regular numpy
>> functions, so I think now would be a good time to remove the mlab
>> versions from the pylab namespace.   The question is : how best to do
>> it?  Unfortunately, a lot of people are still using the old load/save
>> and the deprecation warnings are only in 0.99 but not 0.98 so we have
>> not done the typical deprecation cycle.
>>
>> We could create a special purpose deprecation function in pylab which
>> raises a deprecation error: 'use np.loadtxt for plain text, np.load
>> for binary numpy arrays, or mlab.load for old pylab.load
>> compatability').  Ie, not have a functional load/save in the pylab
>> namespace at all.
>
> That is still making an abrupt break in functionality.  It could be made
> more gentle by having the pylab wrapper do something like:
>
> try:
>    return np.load(*args, **kwargs)
> except: # deliberately violate the rule against catching everything
>    warnings.warn("deprecation etc.")
>    return mlab.load(*args, **kwargs)

I thought about this but decided it would be better not to introduce
the additional complexity (yet another load), as it may lead to some
hard to diagnose bugs.  I would prefer do  one release cycle which
warns and calls mlab.load, but I think I prefer over that the a plain
ol error like


In [3]: load('jdh')
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)

/home/jdhunter/<ipython console> in <module>()

/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/pylab.pyc in
load(*args, **kwargs)
    253
    254 def load(*args, **kwargs):
--> 255     raise  NotImplementedError(load.__doc__)
    256 load.__doc__ = """\
    257     pylab no longer provides a load function, though the old pylab

NotImplementedError:     pylab no longer provides a load function,
though the old pylab
    function is still available as matplotlib.mlab.load (you can refer
    to it in pylab as"mlab.load".  However, for plain text files, we
    recommend numpy.loadtxt, which was inspired by the old pylab.load
    but now has more features.  For loading numpy arrays, we recommend
    numpy.load, and its analog numpy.save, which are available in
    pylab as np.load and np.save.


In [4]: save('jdh')
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)

/home/jdhunter/<ipython console> in <module>()

/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/pylab.pyc in
save(*args, **kwargs)
    266
    267 def save(*args, **kwargs):
--> 268     raise  NotImplementedError(save.__doc__)
    269 save.__doc__ = """\
    270     pylab no longer provides a save function, though the old pylab

NotImplementedError:     pylab no longer provides a save function,
though the old pylab
    function is still available as matplotlib.mlab.save (you can still
    refer to it in pylab as "mlab.save".  However, for plain text
    files, we recommend numpy.savetxt.  For saving numpy arrays,
    we recommend numpy.save, and its analog numpy.load, which are
    available in pylab as np.save and np.load.

John Hunter wrote:
> On Mon, Aug 3, 2009 at 2:15 PM, John Hunter<jd...@gm...> wrote:
> 
>> This may have been Eric's change to clean up the pylab imports -- all
>> the mlab imports come before the pylab imports.  Was this intentional?
>>  My guess is not, since np.loadtxt is the replacement for pylab.load.
>> I prefer to do what we are currently doing, which is issue the
>> deprecation warning, but I wanted to at least find out if this change
>> was intentional (I noticed it because it broke
>> docs/pyplot/plotmap.py), which tries to load some basemap data:
> 
> Correction, I had confused myself for a minute thinking numpy.load was
> the old numpy.load which handled plain text files, ie what became
> loadtxt.  np.load and np.save are too important as regular numpy
> functions, so I think now would be a good time to remove the mlab
> versions from the pylab namespace.   The question is : how best to do
> it?  Unfortunately, a lot of people are still using the old load/save
> and the deprecation warnings are only in 0.99 but not 0.98 so we have
> not done the typical deprecation cycle.
> 
> We could create a special purpose deprecation function in pylab which
> raises a deprecation error: 'use np.loadtxt for plain text, np.load
> for binary numpy arrays, or mlab.load for old pylab.load
> compatability').  Ie, not have a functional load/save in the pylab
> namespace at all.

That is still making an abrupt break in functionality.  It could be made 
more gentle by having the pylab wrapper do something like:

try:
     return np.load(*args, **kwargs)
except: # deliberately violate the rule against catching everything
     warnings.warn("deprecation etc.")
     return mlab.load(*args, **kwargs)

In the next release the warning could be changed to an error, and in the 
release after that pylab.load could simply be numpy.load

Eric

> 
> JDH
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Aug 3, 2009 at 2:15 PM, John Hunter<jd...@gm...> wrote:

> This may have been Eric's change to clean up the pylab imports -- all
> the mlab imports come before the pylab imports.  Was this intentional?
>  My guess is not, since np.loadtxt is the replacement for pylab.load.
> I prefer to do what we are currently doing, which is issue the
> deprecation warning, but I wanted to at least find out if this change
> was intentional (I noticed it because it broke
> docs/pyplot/plotmap.py), which tries to load some basemap data:

Correction, I had confused myself for a minute thinking numpy.load was
the old numpy.load which handled plain text files, ie what became
loadtxt.  np.load and np.save are too important as regular numpy
functions, so I think now would be a good time to remove the mlab
versions from the pylab namespace.   The question is : how best to do
it?  Unfortunately, a lot of people are still using the old load/save
and the deprecation warnings are only in 0.99 but not 0.98 so we have
not done the typical deprecation cycle.

We could create a special purpose deprecation function in pylab which
raises a deprecation error: 'use np.loadtxt for plain text, np.load
for binary numpy arrays, or mlab.load for old pylab.load
compatability').  Ie, not have a functional load/save in the pylab
namespace at all.

JDH

I just noticed pylab.load now points to np.load when it used to point
to mlab.load

In [17]: import pylab

In [18]: import numpy

In [19]: pylab.load is numpy.load
Out[19]: True

This may have been Eric's change to clean up the pylab imports -- all
the mlab imports come before the pylab imports.  Was this intentional?
 My guess is not, since np.loadtxt is the replacement for pylab.load.
I prefer to do what we are currently doing, which is issue the
deprecation warning, but I wanted to at least find out if this change
was intentional (I noticed it because it broke
docs/pyplot/plotmap.py), which tries to load some basemap data:

In [12]: x = pylab.load('/home/jdhunter/python/svn/matplotlib/trunk/htdocs/screenshots/data/etopo20data.gz')
---------------------------------------------------------------------------
IOError                                   Traceback (most recent call last)

/home/jdhunter/mpl99/doc/api/<ipython console> in <module>()

/home/jdhunter/dev/lib/python2.5/site-packages/numpy/lib/io.pyc in
load(file, mmap_mode)
    199         except:
    200             raise IOError, \
--> 201                 "Failed to interpret file %s as a pickle" % repr(file)
    202
    203 def save(file, arr):


JDH

I just did a clean install into a new virtualenv and I get the following 
when running mathtext_demo.py:

/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py:165: 
UserWarning: matplotlib was compiled without mathtex support. Math will 
not be rendered.
  'Math will not be rendered.')

Is there an additional step to install mathtex?  I thought the goal was 
to make "python setup.py install" work out of the box.

Cheers,
Mike


Freddie Witherden wrote:
> Hi all,
>
> I have just finished going over the mathtex branch and it appears to  
> be totally feature complete. Furthermore, by using the newest version  
> of mathtex it also benefits from the recent rendering improvements.
>
> I am therefore interested to hear peoples comments on it/what can be  
> improved. Furthermore, would it be worthwhile back-porting some of the  
> rendering changes/enhancements I've made to mathtex to matplotlib?  
> (Which I am more than happy to do.)
>
> Regards, Freddie.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On 2009-08-02 00:18, Michiel de Hoon wrote:
>> Is one of these two locations preferable for the
>> default?
>
> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/
>
> is preferable.
>
> The location depends on whether the user has a framework Python or a normal static Python installed. For GUI programs, a framework Python is preferable. For the Mac/README in the Python source distribution:

No, /Library/Python/2.5/site-packages/ is the location that users can install 
third-party packages for the System Python (because one shouldn't touch 
/System/Library/.../site-packages/). If you use the System Python to install 
your package or run bdist_mpkg, it has configured its distutils to default to 
installing there. If you use the www.python.org build of Python, its default is 
still its internal /Library/Frameworks/.../site-packages/.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Hi all,

I have just finished going over the mathtex branch and it appears to  
be totally feature complete. Furthermore, by using the newest version  
of mathtex it also benefits from the recent rendering improvements.

I am therefore interested to hear peoples comments on it/what can be  
improved. Furthermore, would it be worthwhile back-porting some of the  
rendering changes/enhancements I've made to mathtex to matplotlib?  
(Which I am more than happy to do.)

Regards, Freddie.

Hello,

I'm working on a pyglet backend for matplotlib and I have a few
questions. Currently the renderer is a subclass of the Agg renderer and
it seems to be working properly. I intended only to re-implement the
'draw_image' method to benefit from fast image display using
OpenGL/texture/shader. My first test was then to have a dummy draw_image
image and I expected command like imshow to not display anything at all
but is it not the case. Am I wrong in my assumption regarding the
purpose of the 'draw_image' method ?


Experimental code is located at:

backend:
http://www.loria.fr/~rougier/tmp/backend_pygletagg.py
http://www.loria.fr/~rougier/tmp/backend_pyglet.py

test:
http://www.loria.fr/~rougier/tmp/dynamic_image_pyglet.py
http://www.loria.fr/~rougier/tmp/test_backend_pyglet.py



Nicolas

> Is one of these two locations preferable for the
> default?

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/

is preferable.

The location depends on whether the user has a framework Python or a normal static Python installed. For GUI programs, a framework Python is preferable. For the Mac/README in the Python source distribution:

1. Why would I want a framework Python instead of a normal static Python?
--------------------------------------------------------------------------

The main reason is because you want to create GUI programs in Python. With the exception of X11/XDarwin-based GUI toolkits all GUI programs need to be run from a fullblown MacOSX application (a ".app" bundle).


(I'd like to add to this that X11/XDarwin-based GUI toolkits, such as PyGTK, also work fine with a framework Python).


> Is there a way to inform bdist_mkpg of the desired install target?

From what I've seen, bdist_mpkg uses
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/
if the Python creating the package is a framework Python.


--Michiel




--- On Sat, 8/1/09, John Hunter <jd...@gm...> wrote:

> From: John Hunter <jd...@gm...>
> Subject: [matplotlib-devel] mkpg on OSX
> To: "matplotlib development list" <mat...@li...>
> Date: Saturday, August 1, 2009, 1:43 PM
> I tried testing the OSX binaries I
> built Friday on my local OSX laptop
> today, and had a problem with the mkpg installer
> 
> http://drop.io/xortel1/asset/matplotlib-0-99-0-rc1-py2-5-macosx10-5-zip
> 
> On the sage box I used to do the builds, the default python
> path that
> the installer picks up is
> 
>   /Library/Python/2.5/site-packages
> 
> and this is where it put mpl when I ran the installer on my
> local box.
>  But then when I try and import matplotlib on my local box
> w/o
> modifying the PYTHONPATH, I can't find it because my local
> python is
> looking in
> 
>  
> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/
> 
> Is one of these two locations preferable for the
> default?  Is there a
> way to inform bdist_mkpg of the desired install target? Is
> there any
> notion of the right way to do things w/ python on OSX?
> 
> JDH
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and
> deployment - and focus on 
> what you do best, core application coding. Discover what's
> new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 


      

On Sat, Aug 1, 2009 at 8:35 PM, Ryan May<rm...@gm...> wrote:
> I'll be there on the ground, though my flight leaves 1:50 on Sunday.  We
> might also consider doing some discussions during the week, maybe a BoF?

Great, hopefully you can join us Saturday.   If there is anything in
particular you want to work on during the sprint, let me know.  As for
a BoF, I generally find discussions less useful than coding, since
python is such a great prototyping language, though there will be many
opportunities to brainstorm over beers, etc...  Are there topics in
particular you have in mind?

JDH

I'll be there on the ground, though my flight leaves 1:50 on Sunday.  We
might also consider doing some discussions during the week, maybe a BoF?

Ryan

On Sat, Aug 1, 2009 at 11:41 AM, John Hunter <jd...@gm...> wrote:

> On Sat, Aug 1, 2009 at 1:39 AM, Andrew Straw<str...@as...> wrote:
>
> > I'll be there, too. I think an MPL sprint would be very good.
>
> Great -- give that we have JJ (remotely), you and me confirmed, two
> obvious topics to work on are:
>
>  * buildbot : JDH & Andrew
>
>  * integrating JJ's curvilinear ticking w/ Andrew's spines
>
> I'm up for anything else that people want to work on, but at least
> we'll have the right people in the room, if only virtually, for these
> topics.  Anyone else planning on attending on-ground or on-line?
>
> JDH
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,

On 1 Aug 2009, at 18:43, John Hunter wrote:

> I tried testing the OSX binaries I built Friday on my local OSX laptop
> today, and had a problem with the mkpg installer
>
> http://drop.io/xortel1/asset/matplotlib-0-99-0-rc1-py2-5-macosx10-5- 
> zip
>
> On the sage box I used to do the builds, the default python path that
> the installer picks up is
>
>  /Library/Python/2.5/site-packages
>
> and this is where it put mpl when I ran the installer on my local box.
> But then when I try and import matplotlib on my local box w/o
> modifying the PYTHONPATH, I can't find it because my local python is
> looking in
>
>  /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ 
> site-packages/
>
> Is one of these two locations preferable for the default?  Is there a
> way to inform bdist_mkpg of the desired install target? Is there any
> notion of the right way to do things w/ python on OSX?

 From what I can tell /Library/Python/2.5/site-packages is the  
default. All I have in /Library/Frameworks are those such as Qt, CG  
and other things which I have installed. VirtualBox and PyQt both  
install to  /Library/Python/2.5/site-packages

The README in /Library/Python/2.5/site-packages make reference to a  
site.py file for 'more information' on site packages. I am unsure what  
exactly is meant by this.

Might be worth seeing how PyQt or VirtualBox pull it off. Although I  
am unsure if the installer code for either is open source.

Regards, Freddie.

I tried testing the OSX binaries I built Friday on my local OSX laptop
today, and had a problem with the mkpg installer

http://drop.io/xortel1/asset/matplotlib-0-99-0-rc1-py2-5-macosx10-5-zip

On the sage box I used to do the builds, the default python path that
the installer picks up is

  /Library/Python/2.5/site-packages

and this is where it put mpl when I ran the installer on my local box.
 But then when I try and import matplotlib on my local box w/o
modifying the PYTHONPATH, I can't find it because my local python is
looking in

  /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/

Is one of these two locations preferable for the default?  Is there a
way to inform bdist_mkpg of the desired install target? Is there any
notion of the right way to do things w/ python on OSX?

JDH

On Sat, Aug 1, 2009 at 1:39 AM, Andrew Straw<str...@as...> wrote:

> I'll be there, too. I think an MPL sprint would be very good.

Great -- give that we have JJ (remotely), you and me confirmed, two
obvious topics to work on are:

  * buildbot : JDH & Andrew

  * integrating JJ's curvilinear ticking w/ Andrew's spines

I'm up for anything else that people want to work on, but at least
we'll have the right people in the room, if only virtually, for these
topics.  Anyone else planning on attending on-ground or on-line?

JDH

John Hunter wrote:
> On Thu, Jul 30, 2009 at 1:56 PM, Jae-Joon Lee<lee...@gm...> wrote:
>
>   
>>  ps. Are we having a sprint during the scipy conference by the way? I
>> may join remotely.
>>     
>
> I'll definitely be there Sat and Sun, so having you join in remotely
> would be great.  I haven't organized any official topics yet, but we
> have plenty to do so I think we'll just look at the skills and
> interests of those joining live or virtually and hammer away.
>   

I'll be there, too. I think an MPL sprint would be very good.