matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> 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

John,

Your solution is certainly fine with me.

Eric
> 
> 
> 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.

Hi,

On 3 Aug 2009, at 17:39, Michael Droettboom wrote:
> Is there an additional step to install mathtex?  I thought the goal  
> was to make "python setup.py install" work out of the box.

This was the goal and I got quite close to achieving it. This latter  
parts of this thread deal with the specific issues (relating to the  
directory structure chosen) http://sourceforge.net/mailarchive/forum.php?thread_name=A97F3AC6-1434-4E6D-AF39-9DBD4653BCB4%40witherden.org&forum_name=matplotlib-devel

So I was advised by John to just assume mathtex is installed.  
Thankfully this is not hard to do -- and is covered in the INSTALL  
file. It is basically a case of changing to lib/mathtext and running  
python setup.py build && python setup.py install.

The branch handles the checking out of mathtex from its svn repo  
(svn:externals) and any system that can build matplotlib can also  
build mathtex. Currently the HEAD revision is checked out. This is  
easy to change.

There is a slight performance penalty associated with using mathtex --  
due to each expression being parsed twice -- where matplotlib caches  
parsed expressions. If this is a problem let me know and I'll work on  
something.

Regards, Freddie.

John Hunter <jd...@gm...> writes:

> On Wed, Jul 22, 2009 at 8:15 AM, Jouni K. Seppänen<jk...@ik...> wrote:
>
>> I finally committed the "boilerplate" variant. It seems to pass the
>> tests in pylab_examples, but now might be a good time for everyone to
>> take a look to see if I have broken anything.
>
> There is one problem, but I am not sure what the workaround is yet.
> The doc strings in rest are broken, eg compare the pyplot Line2D
> properties with the Axes equivalent:

I think I have fixed this, but I'm having some trouble building the docs
myself -- could you check if the hardcopy docs come out right now?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

In article 
<88e...@ma...>,
 John Hunter <jd...@gm...> 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-package
>   s/
> 
> 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?

I just tried the 0.99.0 installation myself and ran into the same issue. 
I expected it to work with my python.org python, which would be the 
latter path, but instead it went into /Library/Python/2.5/site-packages 
(where my normal python.org python can't find it).

If you are using bdist_mpkg then it should do the right thing as long as 
you build the python with your python.org python 
(/Library/Frameworks...) instead of the system python.

-- Russell

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