matplotlib-devel Mailing List for matplotlib

On Sat, Jul 10, 2010 at 4:13 PM, Ryan May <rm...@gm...> wrote:
> both, specifically check_for_tk(). Here we catch the actual exception
> object and use it to print an error message. If anyone has a
> suggestion (not print the error? Look at the exception stack?), I'd
> love to be able to commit these so that at least setup.py runs.

You might want to paste cbook.exception_to_str into setupext.py and
use that to get the error message.

On Sat, Jul 10, 2010 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
> In case anyone working on mpl development missed it, this may be of
> interest.  I think it's time for us to work seriously on supporting
> python 2 and 3 in the same codebase, following numpy's lead.  I hope we
> can make the transition to git first--and soon.
I agree completely. I've looked at our code base ever so briefly in
terms of getting setup.py to run. I just committed some changes that
work cleanly on both versions and have some more for setupext.py. My
problem is that I can't find a way to make setupext.py run clean on
both, specifically check_for_tk(). Here we catch the actual exception
object and use it to print an error message. If anyone has a
suggestion (not print the error? Look at the exception stack?), I'd
love to be able to commit these so that at least setup.py runs.

Has anyone looked to see if our other dependencies are ported yet:
dateutil, pytz? What about the GUI toolkits? PyQt4 was the only one I
found last I looked.

Ryan

> -------- Original Message --------
> Subject: [Numpy-discussion] ANN: Numpy runs on Python 3
> Date: Sat, 10 Jul 2010 14:30:06 +0000 (UTC)
> From: Pauli Virtanen <pa...@ik...>
> Reply-To: Discussion of Numerical Python <num...@sc...>
> To: num...@sc...
>
> Hi,
>
> As many of you probably already know, Numpy works fully on Python 3 and
> Python 2, with a *single code base*, since March. This work is scheduled
> to be included in the next releases 1.5 and 2.0.
>
> Porting Scipy to work on Python 3 has proved to be much less work, and
> will probably be finished "soon". (Ongoing work is here: http://
> github.com/cournape/scipy3/commits/py3k , http://github.com/pv/scipy-work/
> commits/py3k )
>
> For those who are interested in already starting to port their stuff to
> Python 3, you can use Numpy's SVN trunk version. Grab it:
>
>        svn clone http://svn.scipy.org/svn/numpy/trunk/ numpy
>        cd numpy
>        python3 setup.py build
>
> An important point is that supporting Python 3 and Python 2 in the same
> code base can be done, and it is not very difficult either. It is also
> much preferable from the maintenance POV to creating separate branches
> for Python 2 and 3. We attempted to log changes needed in Numpy at
>
>        http://projects.scipy.org/numpy/browser/trunk/doc/Py3K.txt
>
> which may be useful (although not completely up-to-date) information for
> people wanting to do make the same transition in their own code.
>
> (Announcement as recommended by our PR department @ EuroScipy :)
>
> --
> Pauli Virtanen
>
> _______________________________________________
> NumPy-Discussion mailing list
> Num...@sc...
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> 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

In case anyone working on mpl development missed it, this may be of 
interest.  I think it's time for us to work seriously on supporting 
python 2 and 3 in the same codebase, following numpy's lead.  I hope we 
can make the transition to git first--and soon.

Eric

-------- Original Message --------
Subject: [Numpy-discussion] ANN: Numpy runs on Python 3
Date: Sat, 10 Jul 2010 14:30:06 +0000 (UTC)
From: Pauli Virtanen <pa...@ik...>
Reply-To: Discussion of Numerical Python <num...@sc...>
To: num...@sc...

Hi,

As many of you probably already know, Numpy works fully on Python 3 and
Python 2, with a *single code base*, since March. This work is scheduled
to be included in the next releases 1.5 and 2.0.

Porting Scipy to work on Python 3 has proved to be much less work, and
will probably be finished "soon". (Ongoing work is here: http://
github.com/cournape/scipy3/commits/py3k , http://github.com/pv/scipy-work/
commits/py3k )

For those who are interested in already starting to port their stuff to
Python 3, you can use Numpy's SVN trunk version. Grab it:

	svn clone http://svn.scipy.org/svn/numpy/trunk/ numpy
	cd numpy
	python3 setup.py build

An important point is that supporting Python 3 and Python 2 in the same
code base can be done, and it is not very difficult either. It is also
much preferable from the maintenance POV to creating separate branches
for Python 2 and 3. We attempted to log changes needed in Numpy at

	http://projects.scipy.org/numpy/browser/trunk/doc/Py3K.txt

which may be useful (although not completely up-to-date) information for
people wanting to do make the same transition in their own code.

(Announcement as recommended by our PR department @ EuroScipy :)

-- 
Pauli Virtanen

_______________________________________________
NumPy-Discussion mailing list
Num...@sc...
http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Jul 9, 2010, at 22:11, John Hunter <jd...@gm...> wrote:

> On Fri, Jul 9, 2010 at 9:59 PM, Eric Firing <ef...@ha...> wrote:
>> On 07/09/2010 11:45 AM, Ryan May wrote:
>>> Hi,
>>> 
>>> I just noticed that ContourSet only inherits ScalarMappable and
>>> ContourLabeller, neither of which is an Artist subclass, which means
>>> ContourSet is not an Artist. (And is why it does not have a remove()
>>> method).  Anyone have any idea why and if we should correct that? I'm
>>> not sure what the ramifications would be.
>> 
>> It's just historical.  Should every plotting command return an Artist,
>> simple or compound?  If so, I suspect contouring is not the only thing
>> that will need refactoring.  I haven't investigated what would be required.
> 
> Ryan, was there a particular use case in which you found that CS was
> not an Artist to be a limitation, or were you just asking out of
> curiosit

Looking at adding a remove method, per another thread. I was confused by the lack of standard machinery, and wasn't sure if I should just add remove method or make it an artist.

Ryan


> 
> JDH
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, Jul 9, 2010 at 9:59 PM, Eric Firing <ef...@ha...> wrote:
> On 07/09/2010 11:45 AM, Ryan May wrote:
>> Hi,
>>
>> I just noticed that ContourSet only inherits ScalarMappable and
>> ContourLabeller, neither of which is an Artist subclass, which means
>> ContourSet is not an Artist. (And is why it does not have a remove()
>> method).  Anyone have any idea why and if we should correct that? I'm
>> not sure what the ramifications would be.
>
> It's just historical.  Should every plotting command return an Artist,
> simple or compound?  If so, I suspect contouring is not the only thing
> that will need refactoring.  I haven't investigated what would be required.

Ryan, was there a particular use case in which you found that CS was
not an Artist to be a limitation, or were you just asking out of
curiosity?

JDH

On 07/09/2010 11:45 AM, Ryan May wrote:
> Hi,
>
> I just noticed that ContourSet only inherits ScalarMappable and
> ContourLabeller, neither of which is an Artist subclass, which means
> ContourSet is not an Artist. (And is why it does not have a remove()
> method).  Anyone have any idea why and if we should correct that? I'm
> not sure what the ramifications would be.

It's just historical.  Should every plotting command return an Artist, 
simple or compound?  If so, I suspect contouring is not the only thing 
that will need refactoring.  I haven't investigated what would be required.

Eric

>
> Ryan
>

On Fri, Jul 9, 2010 at 5:22 PM, Ryan May <rm...@gm...> wrote:

> I've been "hard" at work over the last couple of months putting
> together a set of classes that simplifies the creation of animations
> in matplotlib. This started when I resurrected some old code for

Very nice -- people are going to really like this. I've had several
requests personally to add something like this so thanks for doing it
:-)

Some rapid fire comments, in no particular order

  * on recent ubuntu linux with gtkagg, dynamic_image has a "one
pixel" bug on the right side if blit=True.  I suspect this has nothing
to do with your package and everything to do with gtkagg blitting code
having an off-by-one error somewhere.  I added this to the tracker:
https://sourceforge.net/tracker/?func=detail&aid=3027636&group_id=80706&atid=560720

  * this is completely un-thought out, but could we define a subclass
of TimedAnimation to work like an iterator so users could do the
natural thing :

  line, = ax.plot(something)
  for frame in SomeTimedAnimation(fig, blit=True):
      line.set_data(mydata)
      frame.update()

or something along those lines....

* when you integrate this into trunk, I would like to see widgets.py
upgraded to use it.  This is not a requirement and I would be happy to
help with it, but it is a good way to push on the new API and expand
the test cases.

* I am happy to see this pushed into trunk at any time.  I would not
push it into the branch, but we can do a 1.1 trunk release as soon as
we are ready (release early, release often).  Putting it in the trunk
will facilitate testing and other developer contributions.  But if
you'd rather leave it in github for a while, I have no problem with
that either.

* you hardcode the artist visible state True/False in ArtistAnimation,
which overrides any settings the users may be trying to control. Not
sure if this is a problem, but it's something to think about.  When
you set False in ArtistAnimation._init_draw, should you first store
the current state so you can restore the userland settings?  You
comment that maybe you should be integrating with the "animated"
property.  This is essentially what this is for, if animated is set it
should not be used in drawing the background.   Not sure if this
matters since it may be sensible to assume they are handing you
control of visibility in ArtistAnimation, just throwing it out there.

* in Animation.save, why do you set blit=False?  When making movies,
shouldn't we also depend on the efficiencies of blit?  Or was the
idea: blit is buggy so for production movies turn it off cause I'm
willing to sacrifice performance for quality?
If so, I'd rather try an fix the bugs....or expose blit as a kwarg.

* a tutorial for the site docs would be awesome.  It's one of the big
missing pieces in the docs, so this would be a good time to add it.

* when you include animation.py in the trunk, would you write the examples as

  import matplotlib.animation as animation
  ani = animation.FuncAnimation(fig, ...)

  per the style guidelines in the coding guide.

* let's preserve the old gui specific examples in a subdir of
examples/animation, so people who need bare metal control will still
have examples to follow.  You can add a README in that dir suggesting
the use of the new API unless necessary.

Nice work.

JDH