matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] 'NoneType' object has no attribute 'endswith' when running tests in a chroot

[Michael D. <md...@st...>]

On 05/20/2012 12:51 PM, Sandro Tosi wrote:
> Hello,
> I've been trying to fix this problem for hours, and it's getting me
> mad but to no conclusion, so I'm asking here.
>
> In Debian we build our packges in a chroot, with all the minimum
> dependecies needed to build the package (to guarantee reproducibility
> and avoid weird effect of local installed packages), and so also the
> unittests are runt here. While enabling the matplotlib unittest in
> that chroot, I'm getting this error:
>
> ======================================================================
> ERROR: matplotlib.tests.test_axes.test_arc_ellipse.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "/usr/lib/python2.6/dist-packages/nose/case.py", line 197, in runTest
>      self.test(*self.arg)
>    File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/testing/decorators.py",
> line 36, in failer
>      result = f(*args, **kwargs)
>    File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/testing/decorators.py",
> line 128, in do_test
>      figure.savefig(actual_fname)
>    File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/figure.py",
> line 1185, in savefig
>      self.canvas.print_figure(*args, **kwargs)
>    File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/backend_bases.py",
> line 2021, in print_figure
>      **kwargs)
>    File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/backend_bases.py",
> line 1789, in print_pdf
>      return pdf.print_pdf(*args, **kwargs)
>    File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/backends/backend_pdf.py",
> line 2180, in print_pdf
>      file = PdfFile(filename)
>    File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/backends/backend_pdf.py",
> line 378, in __init__
>      rcParams['datapath'], 'fonts', 'pdfcorefonts')
>    File "/usr/lib/python2.6/posixpath.py", line 67, in join
>      elif path == '' or path.endswith('/'):
> AttributeError: 'NoneType' object has no attribute 'endswith'

I'm not sure about this one.  Could it be due to not having a font cache 
in ~/.matplotlib?

>
> (repeated for several times, it seems like a patter, given the output
> of the test execution is:
>
> ..K.............EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK..EK.EK.EK.EK.EK.EK.EKK...EK...EK.EK..EKEK..EK.EK.EK.EK.EK..EK.EK.EK[....]
>
> and so on) so it seems the code can't find the datapath location. In
> order to fix that, I'm calling the test suite like this:

This is most likely due to some of the testing dependencies not being 
present.  matplotlib uses ghostscript for rendering PDF and inkscape for 
rendering SVG (but only when testing).  See this documentation:

http://matplotlib.sourceforge.net/devel/coding_guide.html#testing

(Note the the PIL requirement goes away with matplotlib git master -- 
it's only required for the 1.1.x series).

>
> PYTHONPATH=build/lib.linux-x86_64-2.6 \
>          MATPLOTLIBDATA=/tmp/buildd/matplotlib-1.1.1~rc1/lib/matplotlib/mpl-data/
> \
>          MPLCONFIGDIR=. \
>                  python2.6 -c "import matplotlib as m ; m.test(verbosity=1)"
>
> and in . there's a matplotlibrc file with simply:
>
>    datapath : /tmp/buildd/matplotlib-1.1.1~rc1/lib/matplotlib/mpl-data/
>
> in it; but still I got all of these failures. Anyone knows where I can
> look to fix that?
>
> Thanks in advance,
Cheers,
Mike

[matplotlib-devel] 'NoneType' object has no attribute 'endswith' when running tests in a chroot

[Sandro T. <mo...@de...>]

Hello,
I've been trying to fix this problem for hours, and it's getting me
mad but to no conclusion, so I'm asking here.

In Debian we build our packges in a chroot, with all the minimum
dependecies needed to build the package (to guarantee reproducibility
and avoid weird effect of local installed packages), and so also the
unittests are runt here. While enabling the matplotlib unittest in
that chroot, I'm getting this error:

======================================================================
ERROR: matplotlib.tests.test_axes.test_arc_ellipse.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/testing/decorators.py",
line 36, in failer
    result = f(*args, **kwargs)
  File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/testing/decorators.py",
line 128, in do_test
    figure.savefig(actual_fname)
  File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/figure.py",
line 1185, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/backend_bases.py",
line 2021, in print_figure
    **kwargs)
  File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/backend_bases.py",
line 1789, in print_pdf
    return pdf.print_pdf(*args, **kwargs)
  File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/backends/backend_pdf.py",
line 2180, in print_pdf
    file = PdfFile(filename)
  File "/tmp/buildd/matplotlib-1.1.1~rc1/build/lib.linux-x86_64-2.6/matplotlib/backends/backend_pdf.py",
line 378, in __init__
    rcParams['datapath'], 'fonts', 'pdfcorefonts')
  File "/usr/lib/python2.6/posixpath.py", line 67, in join
    elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'

(repeated for several times, it seems like a patter, given the output
of the test execution is:

..K.............EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK.EK..EK.EK.EK.EK.EK.EK.EKK...EK...EK.EK..EKEK..EK.EK.EK.EK.EK..EK.EK.EK[....]

and so on) so it seems the code can't find the datapath location. In
order to fix that, I'm calling the test suite like this:

PYTHONPATH=build/lib.linux-x86_64-2.6 \
        MATPLOTLIBDATA=/tmp/buildd/matplotlib-1.1.1~rc1/lib/matplotlib/mpl-data/
\
        MPLCONFIGDIR=. \
                python2.6 -c "import matplotlib as m ; m.test(verbosity=1)"

and in . there's a matplotlibrc file with simply:

  datapath : /tmp/buildd/matplotlib-1.1.1~rc1/lib/matplotlib/mpl-data/

in it; but still I got all of these failures. Anyone knows where I can
look to fix that?

Thanks in advance,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Michael D. <md...@st...>]

On 05/14/2012 12:58 PM, Christoph Gohlke wrote:
>
> On 5/14/2012 7:43 AM, Michael Droettboom wrote:
>> On 05/12/2012 01:33 PM, Christoph Gohlke wrote:
>>>
>>> On 5/12/2012 6:16 AM, Michael Droettboom wrote:
>>>> On 05/12/2012 07:21 AM, Mark Lawrence wrote:
>>>>> My original offer (made several months ago) to help test this on
>>>>> Windows
>>>>> still stands :)
>>>>>
>>>> Thanks. Does git master build and pass the unit tests on Windows?
>>>>
>>>> Mike
>>>>
>>> git master builds and tests OK on win32-py2.7.
>>>
>>> With the attached patch git master builds and works (in practice) OK
>>> on win-amd64-py3.2 but there are many test errors of type
>>> "RuntimeError: Could not open facefile X:\Python32\...\ttf\Vera.ttf;
>>> Cannot_Open_Resource". I do delete the ~\.matplotlib folder before
>>> running the tests and can verify that
>>> FT2Font(r"X:\Python32\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf")
>>> works.
>> That looks like the same issue we were having on the 1.1.x branch --
>> that it's running out of file handles -- that I thought was fixed by
>> this PR:
>>
>> https://github.com/matplotlib/matplotlib/pull/798
>>
>>
>> PR798 works for Python 2.7. But under Python 3.2 the tests are still
>> running out of file handles. Manually increasing the open files limit
>> helps (only one test fails).
>>
Ah, I guess that makes sense given how destructors are handled 
differently on Python 3.  I have some thoughts on this that I might put 
into a PR.  I don't have access to a Windows box at the moment, so I may 
need some help testing.

Mike

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Christoph G. <cg...@uc...>]

On 5/14/2012 7:43 AM, Michael Droettboom wrote:
> On 05/12/2012 01:33 PM, Christoph Gohlke wrote:
>>
>>
>> On 5/12/2012 6:16 AM, Michael Droettboom wrote:
>>> On 05/12/2012 07:21 AM, Mark Lawrence wrote:
>>>>
>>>> My original offer (made several months ago) to help test this on
>>>> Windows
>>>> still stands :)
>>>>
>>> Thanks. Does git master build and pass the unit tests on Windows?
>>>
>>> Mike
>>>
>>
>> git master builds and tests OK on win32-py2.7.
>>
>> With the attached patch git master builds and works (in practice) OK
>> on win-amd64-py3.2 but there are many test errors of type
>> "RuntimeError: Could not open facefile X:\Python32\...\ttf\Vera.ttf;
>> Cannot_Open_Resource". I do delete the ~\.matplotlib folder before
>> running the tests and can verify that
>> FT2Font(r"X:\Python32\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf")
>> works.
> That looks like the same issue we were having on the 1.1.x branch --
> that it's running out of file handles -- that I thought was fixed by
> this PR:
>
> https://github.com/matplotlib/matplotlib/pull/798
>
> Or are we seeing something else here?
>
> Mike
>

PR798 works for Python 2.7. But under Python 3.2 the tests are still 
running out of file handles. Manually increasing the open files limit 
helps (only one test fails).

Christoph

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Michael D. <md...@st...>]

On 05/12/2012 05:56 AM, Sandro Tosi wrote:
> Hello,
> as you may be aware of, in 1 month (more or less) Debian will freeze,
> that means that no new upstream releases will be allowed in the
> upcoming release, only fixex for important bugs.
>
> Currently in Debian archive we have 1.1.1rc1 . Recent mails have
> mentioned that the next release will be py3k enabled. Well, what are
> you're plans to release such version? :)

I don't think we have a timeframe on that yet.  Getting out a solid, 
stable 1.1.1 (without Py3k support) I think is a higher priority right now.

>
> It would be really awesome to have a python3 matplotlib in Debian, and
> i'd be happy to test any new RC you'd like to release.
>
To get this going, perhaps I'll go ahead and make a branch off of master 
for 1.2.x and we could start testing it on all the platforms and see how 
far it feels from releasable state.  There are few PRs in the queue that 
are simple yet critical that should get in there first.

Mike

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Michael D. <md...@st...>]

On 05/12/2012 01:33 PM, Christoph Gohlke wrote:
>
>
> On 5/12/2012 6:16 AM, Michael Droettboom wrote:
>> On 05/12/2012 07:21 AM, Mark Lawrence wrote:
>>>
>>> My original offer (made several months ago) to help test this on 
>>> Windows
>>> still stands :)
>>>
>> Thanks.  Does git master build and pass the unit tests on Windows?
>>
>> Mike
>>
>
> git master builds and tests OK on win32-py2.7.
>
> With the attached patch git master builds and works (in practice) OK 
> on win-amd64-py3.2 but there are many test errors of type 
> "RuntimeError: Could not open facefile X:\Python32\...\ttf\Vera.ttf; 
> Cannot_Open_Resource". I do delete the ~\.matplotlib folder before 
> running the tests and can verify that 
> FT2Font(r"X:\Python32\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf") 
> works.
That looks like the same issue we were having on the 1.1.x branch -- 
that it's running out of file handles -- that I thought was fixed by 
this PR:

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

Or are we seeing something else here?

Mike

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Tony Yu <ts...@gm...>]

On Sat, May 12, 2012 at 3:11 PM, Gökhan Sever <gok...@gm...> wrote:

> Hello,
>
> This is a good idea indeed. Especially, when one creates plots for
> presentations and papers. Usually, I make ticks, ticklabels, axes labels,
> line widths, marker sizes as large as possible (within reasonable limits)
> to make them more readable for presentation purposes. However, the same
> element sizes don't look very pretty when I create the same plots for paper
> or vice versa. The solution is either keep modify two rc files or adjust
> one rc file accordingly for each plotting style.
>
> Could the syntax be simplfied a bit? Say rather than using that with
> statement and the extra 4 spaces, can it be just a one simple liner like
> matplotlib.rcuse(mpl_paper.rc) or matplotlib.rcuse(mpl_presentation.rc)?
>

I believe that's what the `rc_file` function does in the
PR<https://github.com/matplotlib/matplotlib/pull/861/files>,
so both use cases are possible. I think it makes sense to allow both.

Cheers,
-Tony


On Fri, May 11, 2012 at 2:17 PM, Paul Ivanov <piv...@gm...> wrote:
>
>> Hey everyone,
>>
>> I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
>> brings the ability to switch between rcParams.
>>
>> Matthew's implementation started with just being able to read in and use
>> an rcParam file, and I suggested the idea of having a context manager,
>> that would allow you to do something like:
>>
>>  with rc_context(fname):
>>      plt.plot()
>>      ...
>>
>> and have the rcParams restored outside of the context.
>>
>> I know there have been a few threads (can't find links now for some
>> reason) and in-person discussions in the past about having this kind of
>> ability in matplotlib, and having an idea of "styles", and Tony Yu
>> implemented a variant of this on top of matplotlib in mpltools [2], but
>> I wanted to ping the list here for other ideas and feelings about such
>> functionality (if anyone can find pointers to previous discussions, that
>> would be very welcome).
>>
>> 1. https://github.com/matplotlib/matplotlib/pull/861
>> 2. https://github.com/tonysyu/mpltools
>>
>> best,
>> --
>> Paul Ivanov
>> 314 address only used for lists,  off-list direct email at:
>> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> Gökhan
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Gökhan S. <gok...@gm...>]

Hello,

This is a good idea indeed. Especially, when one creates plots for
presentations and papers. Usually, I make ticks, ticklabels, axes labels,
line widths, marker sizes as large as possible (within reasonable limits)
to make them more readable for presentation purposes. However, the same
element sizes don't look very pretty when I create the same plots for paper
or vice versa. The solution is either keep modify two rc files or adjust
one rc file accordingly for each plotting style.

Could the syntax be simplfied a bit? Say rather than using that with
statement and the extra 4 spaces, can it be just a one simple liner like
matplotlib.rcuse(mpl_paper.rc) or matplotlib.rcuse(mpl_presentation.rc)?


On Fri, May 11, 2012 at 2:17 PM, Paul Ivanov <piv...@gm...> wrote:

> Hey everyone,
>
> I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
> brings the ability to switch between rcParams.
>
> Matthew's implementation started with just being able to read in and use
> an rcParam file, and I suggested the idea of having a context manager,
> that would allow you to do something like:
>
>  with rc_context(fname):
>      plt.plot()
>      ...
>
> and have the rcParams restored outside of the context.
>
> I know there have been a few threads (can't find links now for some
> reason) and in-person discussions in the past about having this kind of
> ability in matplotlib, and having an idea of "styles", and Tony Yu
> implemented a variant of this on top of matplotlib in mpltools [2], but
> I wanted to ping the list here for other ideas and feelings about such
> functionality (if anyone can find pointers to previous discussions, that
> would be very welcome).
>
> 1. https://github.com/matplotlib/matplotlib/pull/861
> 2. https://github.com/tonysyu/mpltools
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists,  off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Gökhan

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Christoph G. <cg...@uc...>]

On 5/12/2012 6:16 AM, Michael Droettboom wrote:
> On 05/12/2012 07:21 AM, Mark Lawrence wrote:
>>
>> My original offer (made several months ago) to help test this on Windows
>> still stands :)
>>
> Thanks.  Does git master build and pass the unit tests on Windows?
>
> Mike
>

git master builds and tests OK on win32-py2.7.

With the attached patch git master builds and works (in practice) OK on 
win-amd64-py3.2 but there are many test errors of type "RuntimeError: 
Could not open facefile X:\Python32\...\ttf\Vera.ttf; 
Cannot_Open_Resource". I do delete the ~\.matplotlib folder before 
running the tests and can verify that 
FT2Font(r"X:\Python32\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf") 
works.

Christoph

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Michael D. <md...@st...>]

On 05/12/2012 07:21 AM, Mark Lawrence wrote:
>
> My original offer (made several months ago) to help test this on Windows
> still stands :)
>
Thanks.  Does git master build and pass the unit tests on Windows?

Mike

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Mark L. <bre...@ya...>]

On 12/05/2012 11:01, Thomas Kluyver wrote:
> On 12 May 2012 10:56, Sandro Tosi<mo...@de...>  wrote:
>> It would be really awesome to have a python3 matplotlib in Debian, and
>> i'd be happy to test any new RC you'd like to release.
>
> Just to mention: I've set up a daily builds PPA for matplotlib, and
> it's been happily producing Python 3 builds for a while, so it looks
> like it should be fairly painless:
> https://code.launchpad.net/~takluyver/+archive/matplotlib-daily
>
> Thanks,
> Thomas
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

My original offer (made several months ago) to help test this on Windows 
still stands :)

-- 
Cheers.

Mark Lawrence.

Re: [matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Thomas K. <th...@kl...>]

On 12 May 2012 10:56, Sandro Tosi <mo...@de...> wrote:
> It would be really awesome to have a python3 matplotlib in Debian, and
> i'd be happy to test any new RC you'd like to release.

Just to mention: I've set up a daily builds PPA for matplotlib, and
it's been happily producing Python 3 builds for a while, so it looks
like it should be fairly painless:
https://code.launchpad.net/~takluyver/+archive/matplotlib-daily

Thanks,
Thomas

[matplotlib-devel] Plans for matplotlib py3k/final release (and impact on Debian)

[Sandro T. <mo...@de...>]

Hello,
as you may be aware of, in 1 month (more or less) Debian will freeze,
that means that no new upstream releases will be allowed in the
upcoming release, only fixex for important bugs.

Currently in Debian archive we have 1.1.1rc1 . Recent mails have
mentioned that the next release will be py3k enabled. Well, what are
you're plans to release such version? :)

It would be really awesome to have a python3 matplotlib in Debian, and
i'd be happy to test any new RC you'd like to release.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Paul I. <piv...@gm...>]

On Fri, May 11, 2012 at 2:45 PM, Michael Droettboom <md...@st...> wrote:
> The next major release (which will include Python 3 support) bumps the
> minimum requirement up to Python 2.6.

Right, this was my working assumption when I made the 'with' statement
suggestion. Since it's a new feature, it won't make it into the 1.1.x
series, and in the next  major relase (>= py2.6) we can safely use
context managers.

best
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Benjamin R. <ben...@ou...>]

On Friday, May 11, 2012, Michael Droettboom wrote:

>  The minimum requirement of the 1.1 series is still Python 2.4, believe it
> or not, though I'm not sure practically what the minimum numpy is.
>
> The next major release (which will include Python 3 support) bumps the
> minimum requirement up to Python 2.6.
>
> Mike
>

The numpy requirement is whichever one introduced no.nextafter(). I beleive
that is 1.4.

Ben Root

>

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Warren W. <war...@en...>]

On Fri, May 11, 2012 at 4:45 PM, Michael Droettboom <md...@st...> wrote:

>  The minimum requirement of the 1.1 series is still Python 2.4, believe it
> or not, though I'm not sure practically what the minimum numpy is.
>


It is at least 1.4; see this thread:

http://old.nabble.com/Upgraded-to-1.1.0,-now-only-line-graphs-work!-td32833484.html

Warren



>
> The next major release (which will include Python 3 support) bumps the
> minimum requirement up to Python 2.6.
>
> Mike
>
>
> On 05/11/2012 05:32 PM, Warren Weckesser wrote:
>
>
>
> On Fri, May 11, 2012 at 3:17 PM, Paul Ivanov <piv...@gm...> wrote:
>
>> Hey everyone,
>>
>> I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
>> brings the ability to switch between rcParams.
>>
>> Matthew's implementation started with just being able to read in and use
>> an rcParam file, and I suggested the idea of having a context manager,
>> that would allow you to do something like:
>>
>>  with rc_context(fname):
>>      plt.plot()
>>      ...
>>
>> and have the rcParams restored outside of the context.
>>
>> I know there have been a few threads (can't find links now for some
>> reason) and in-person discussions in the past about having this kind of
>> ability in matplotlib, and having an idea of "styles", and Tony Yu
>> implemented a variant of this on top of matplotlib in mpltools [2], but
>> I wanted to ping the list here for other ideas and feelings about such
>> functionality (if anyone can find pointers to previous discussions, that
>> would be very welcome).
>>
>> 1. https://github.com/matplotlib/matplotlib/pull/861
>> 2. https://github.com/tonysyu/mpltools
>>
>>
>
> You will need Python 2.5 or later to use the 'with' statement.  I think
> that is already a requirement of matplotlib, and this page--which says
> 2.4--is not up to date:
>     http://matplotlib.sourceforge.net/users/installing.html
> I'm sure the minimum version of numpy given there (1.1) is also wrong.
>
> Warren
>
>
>  best,
>> --
>> Paul Ivanov
>> 314 address only used for lists,  off-list direct email at:
>> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Michael D. <md...@st...>]

The minimum requirement of the 1.1 series is still Python 2.4, believe 
it or not, though I'm not sure practically what the minimum numpy is.

The next major release (which will include Python 3 support) bumps the 
minimum requirement up to Python 2.6.

Mike

On 05/11/2012 05:32 PM, Warren Weckesser wrote:
>
>
> On Fri, May 11, 2012 at 3:17 PM, Paul Ivanov <piv...@gm... 
> <mailto:piv...@gm...>> wrote:
>
>     Hey everyone,
>
>     I wanted to highlight Matthew Emmett's (memmett) PR in progress
>     [1] that
>     brings the ability to switch between rcParams.
>
>     Matthew's implementation started with just being able to read in
>     and use
>     an rcParam file, and I suggested the idea of having a context manager,
>     that would allow you to do something like:
>
>      with rc_context(fname):
>          plt.plot()
>          ...
>
>     and have the rcParams restored outside of the context.
>
>     I know there have been a few threads (can't find links now for some
>     reason) and in-person discussions in the past about having this
>     kind of
>     ability in matplotlib, and having an idea of "styles", and Tony Yu
>     implemented a variant of this on top of matplotlib in mpltools
>     [2], but
>     I wanted to ping the list here for other ideas and feelings about such
>     functionality (if anyone can find pointers to previous
>     discussions, that
>     would be very welcome).
>
>     1. https://github.com/matplotlib/matplotlib/pull/861
>     2. https://github.com/tonysyu/mpltools
>
>
>
> You will need Python 2.5 or later to use the 'with' statement.  I 
> think that is already a requirement of matplotlib, and this 
> page--which says 2.4--is not up to date:
> http://matplotlib.sourceforge.net/users/installing.html
> I'm sure the minimum version of numpy given there (1.1) is also wrong.
>
> Warren
>
>
>     best,
>     --
>     Paul Ivanov
>     314 address only used for lists,  off-list direct email at:
>     http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>     ------------------------------------------------------------------------------
>     Live Security Virtual Conference
>     Exclusive live event will cover all the ways today's security and
>     threat landscape has changed and how IT managers can respond.
>     Discussions
>     will include endpoint security, mobile security and the latest in
>     malware
>     threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Tony Yu <ts...@gm...>]

On Fri, May 11, 2012 at 4:20 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Fri, May 11, 2012 at 4:17 PM, Paul Ivanov <piv...@gm...> wrote:
>
>> Hey everyone,
>>
>> I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
>> brings the ability to switch between rcParams.
>>
>> Matthew's implementation started with just being able to read in and use
>> an rcParam file, and I suggested the idea of having a context manager,
>> that would allow you to do something like:
>>
>>  with rc_context(fname):
>>      plt.plot()
>>      ...
>>
>> and have the rcParams restored outside of the context.
>>
>> I know there have been a few threads (can't find links now for some
>> reason) and in-person discussions in the past about having this kind of
>> ability in matplotlib, and having an idea of "styles", and Tony Yu
>> implemented a variant of this on top of matplotlib in mpltools [2], but
>> I wanted to ping the list here for other ideas and feelings about such
>> functionality (if anyone can find pointers to previous discussions, that
>> would be very welcome).
>>
>> 1. https://github.com/matplotlib/matplotlib/pull/861
>> 2. https://github.com/tonysyu/mpltools
>>
>> best,
>> --
>> Paul Ivanov
>> 314 address only used for lists,  off-list direct email at:
>> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>>
>>
> Such a feature would clean up the test code considerably.
>
> Ben Root
>
>
Thanks for pinging me on the PR, Paul. Both the original PR and the
addition of the context manager are great ideas.

Just to clarify, what I implemented in mpltools was a sort-of stylesheet
that can be easily accessed (i.e. you don't have to remember the path, just
the name; and if you forget that, it's listed in a module attribute). But,
I ended up using ConfigObj to parse the rc file instead of using
matplotlib's parser. One major disadvantage of that approach is that
ConfigObj uses a different syntax than matplotlib's rc parameters. In this
sense, the PR would help greatly to fix this discrepancy.

Unfortunately, the PR doesn't completely fulfill my needs. I wanted to
allow multiple stylesheets to be declared in a single file; this means I'd
need to plug into the loop that iterates over the lines of the file. I can
push in that direction on the PR, but I don't want to do that unless people
think this would be more-generally useful.

-Tony

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Warren W. <war...@en...>]

On Fri, May 11, 2012 at 3:17 PM, Paul Ivanov <piv...@gm...> wrote:

> Hey everyone,
>
> I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
> brings the ability to switch between rcParams.
>
> Matthew's implementation started with just being able to read in and use
> an rcParam file, and I suggested the idea of having a context manager,
> that would allow you to do something like:
>
>  with rc_context(fname):
>      plt.plot()
>      ...
>
> and have the rcParams restored outside of the context.
>
> I know there have been a few threads (can't find links now for some
> reason) and in-person discussions in the past about having this kind of
> ability in matplotlib, and having an idea of "styles", and Tony Yu
> implemented a variant of this on top of matplotlib in mpltools [2], but
> I wanted to ping the list here for other ideas and feelings about such
> functionality (if anyone can find pointers to previous discussions, that
> would be very welcome).
>
> 1. https://github.com/matplotlib/matplotlib/pull/861
> 2. https://github.com/tonysyu/mpltools
>
>

You will need Python 2.5 or later to use the 'with' statement.  I think
that is already a requirement of matplotlib, and this page--which says
2.4--is not up to date:
    http://matplotlib.sourceforge.net/users/installing.html
I'm sure the minimum version of numpy given there (1.1) is also wrong.

Warren


best,
> --
> Paul Ivanov
> 314 address only used for lists,  off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Benjamin R. <ben...@ou...>]

On Fri, May 11, 2012 at 4:17 PM, Paul Ivanov <piv...@gm...> wrote:

> Hey everyone,
>
> I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
> brings the ability to switch between rcParams.
>
> Matthew's implementation started with just being able to read in and use
> an rcParam file, and I suggested the idea of having a context manager,
> that would allow you to do something like:
>
>  with rc_context(fname):
>      plt.plot()
>      ...
>
> and have the rcParams restored outside of the context.
>
> I know there have been a few threads (can't find links now for some
> reason) and in-person discussions in the past about having this kind of
> ability in matplotlib, and having an idea of "styles", and Tony Yu
> implemented a variant of this on top of matplotlib in mpltools [2], but
> I wanted to ping the list here for other ideas and feelings about such
> functionality (if anyone can find pointers to previous discussions, that
> would be very welcome).
>
> 1. https://github.com/matplotlib/matplotlib/pull/861
> 2. https://github.com/tonysyu/mpltools
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists,  off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>
Such a feature would clean up the test code considerably.

Ben Root

[matplotlib-devel] switching rc files (and discussion of styles)

[Paul I. <piv...@gm...>]

Hey everyone,

I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
brings the ability to switch between rcParams.

Matthew's implementation started with just being able to read in and use
an rcParam file, and I suggested the idea of having a context manager,
that would allow you to do something like:

  with rc_context(fname):
      plt.plot()
      ...

and have the rcParams restored outside of the context.

I know there have been a few threads (can't find links now for some
reason) and in-person discussions in the past about having this kind of
ability in matplotlib, and having an idea of "styles", and Tony Yu
implemented a variant of this on top of matplotlib in mpltools [2], but
I wanted to ping the list here for other ideas and feelings about such
functionality (if anyone can find pointers to previous discussions, that
would be very welcome).

1. https://github.com/matplotlib/matplotlib/pull/861
2. https://github.com/tonysyu/mpltools

best,
--
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

[matplotlib-devel] Inconsistency between JPEG and PNG images by matplotlib.image.imread()

[kasper <ka...@lo...>]

Hello list,

In working with matplotlib in a Python course we discovered an inconsistency in importing various image files. When importing a JPEG file a numpy array containing ints (0-255) is returned, but when a PNG is imported an array containing floats (0-1) is returned.
The obvious solution is checking for filetype during read and then dividing by 255, but this seems awkward to do outside the library. Also, as discussed at [1] there is the matter of 16 (or 8+) bit images, which might complicate things.
Is there a consensus on how to handle this in code using matplotlib?

Kind regards,

Kasper Loopstra.


[1]: https://github.com/matplotlib/matplotlib/pull/616

Re: [matplotlib-devel] code review: Adding angle offset to start of a pie chart

[Benjamin R. <ben...@ou...>]

On Tue, May 8, 2012 at 6:51 AM, Ezra Peisach <pei...@rc...>wrote:

> After being fed up with no easy way to adjust the start angle of a pie
> chart, I have added an optional argument to axes.pie called startangle
> that allows one to specify the start angle of a pie chart.
>
> I have updated the documentation - but would a new sample file showing a
> side by side output comparison be warranted as well?
> I had to regenerate a portion of pyplot.py using biolerplate.py - and
> that is why the pctdistance changed very slightly....
>
> Feedback welcome.
>
> The url on github is:
>
> https://github.com/epeisach/matplotlib/compare/master...pie_angle
>
>
> Ezra
>
>
Interesting idea.  Why don't you make a pull request and we can see about
putting the final touches on this?

Ben Root

[matplotlib-devel] code review: Adding angle offset to start of a pie chart

[Ezra P. <pei...@rc...>]

After being fed up with no easy way to adjust the start angle of a pie
chart, I have added an optional argument to axes.pie called startangle
that allows one to specify the start angle of a pie chart.

I have updated the documentation - but would a new sample file showing a
side by side output comparison be warranted as well?
I had to regenerate a portion of pyplot.py using biolerplate.py - and
that is why the pctdistance changed very slightly....

Feedback welcome.

The url on github is:

https://github.com/epeisach/matplotlib/compare/master...pie_angle


Ezra

Re: [matplotlib-devel] Qt close bug revisited

[Benjamin R. <ben...@ou...>]

On Saturday, May 5, 2012, Tony Yu wrote:

> I'm getting a strange error when multiple figures are created *without a
> call to show*. Here's the traceback:
>
> Traceback (most recent call last):
>   File
> "/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_qt4.py", line
> 151, in <lambda>
>     lambda: self.close_event())
>   File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py",
> line 1564, in close_event
>     self.callbacks.process(s, event)
> AttributeError: 'FigureCanvasQTAgg' object has no attribute 'callbacks'
>
>
> Here's a simple test case:
>
> import matplotlib.pyplot as plt
> fig = plt.figure()
> plt.plot([0, 1])
> fig = plt.figure()
> plt.plot([0, 1])
>
>
> This issue appears in versions after the PR to fix the Qt4 close bug<https://github.com/matplotlib/matplotlib/pull/716>.
> The error occurs even without the `plot` calls, but the failures aren't as
> consistent (the error will randomly disappear).
>
> Note that sticking a call to `plt.show()` at the end and then manually
> closing the figures does not seem to produce this error. I'm having a
> difficult time locating the source of the bug: when I stick a pdb trace in
> the code, the error doesn't get raised.
>
> Can anyone reproduce this issue?
>
> -Tony
>


My gut tells me it is a race condition. Pdb can make race conditions
disappear because of all the overhead screws around with the timings.
Haven't tried reproducing it yet, though.

Ben Root