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 <pav@...278...>
Reply-To: Discussion of Numerical Python <numpy-discussion@...336...>
To: numpy-discussion@...336...
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
NumPy-Discussion@...336...
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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
···
On Sat, Jul 10, 2010 at 1:32 PM, Eric Firing <efiring@...229...> wrote:
-------- Original Message --------
Subject: [Numpy-discussion] ANN: Numpy runs on Python 3
Date: Sat, 10 Jul 2010 14:30:06 +0000 (UTC)
From: Pauli Virtanen <pav@...278...>
Reply-To: Discussion of Numerical Python <numpy-discussion@...336...>
To: numpy-discussion@...336...
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 , GitHub - pv/scipy-work: Work on Scipy
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
NumPy-Discussion@...336...
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
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 4:13 PM, Ryan May <rmay31@...149...> 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.
That actually uses traceback.print_exc(), which prints out a whole
traceback and looks ugly to me. Instead, I went with sys.exc_info(),
which can get the value of the current exception. It's uglier than
getting the exception object in the except statement, but until we can
just support >= 2.6, we're pretty much stuck with it.
Otherwise, I committed the change to setupext.py. Main changes were to
redo some imports (things moved, renamed) and to make print at least
look like a function. I've actually been running with this in place
for quite a few months with no problems. The results at this point are
that matplotlib installs and runs fine for me on Linux with Python
2.6. With Python 3.1, I get a compile failure with src/ft2font.cpp,
which isn't surprising.
So I guess we're on our way to Python 3!
Ryan
···
On Sat, Jul 10, 2010 at 4:18 PM, John Hunter <jdh2358@...149...> wrote:
On Sat, Jul 10, 2010 at 4:13 PM, Ryan May <rmay31@...149...> 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.
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
I'm a little surprised ft2font is failing, since it is a CXX module,
and I recently upgraded our CXX from v5 to v6 mainly because v6 is
supposed to be python3 compliant, and I thought this would speed us on
our way to python3 support. I thought we would have more problems on
our hand-rolled extensions.,
JDH
···
On Sat, Jul 10, 2010 at 9:38 PM, Ryan May <rmay31@...149...> wrote:
2.6. With Python 3.1, I get a compile failure with src/ft2font.cpp,
which isn't surprising.
Yeah, I remember seeing that. Is there some missing magic to get it to
turn on 3.1 support?
Ryan
···
On Sat, Jul 10, 2010 at 9:49 PM, John Hunter <jdh2358@...149...> wrote:
On Sat, Jul 10, 2010 at 9:38 PM, Ryan May <rmay31@...149...> wrote:
2.6. With Python 3.1, I get a compile failure with src/ft2font.cpp,
which isn't surprising.
I'm a little surprised ft2font is failing, since it is a CXX module,
and I recently upgraded our CXX from v5 to v6 mainly because v6 is
supposed to be python3 compliant, and I thought this would speed us on
our way to python3 support. I thought we would have more problems on
our hand-rolled extensions.,
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma