Python 3.x support

986 views
Skip to first unread message

nak

unread,
Apr 7, 2012, 10:14:19 PM4/7/12
to spyder
I came across a post form 2010 stating there was no python 3 support,
but haven't seen anything since. Does the current version of spyder 2
support python 3?

Pierre Raybaut

unread,
Apr 10, 2012, 8:01:16 AM4/10/12
to spyd...@googlegroups.com
Unfortunately no, Spyder v2 does not support Python 3.

I always planned that Python 3 support would come with Spyder 3. It's
just that Spyder 3 is not out there yet ; its development has not even
started or been scheduled yet.

As a lot of scientific Python developers, we [at my work] are not
ready to migrate to Python 3. I initially thought of migrating
sometime between 2012 and 2014.

So for now, nothing is scheduled yet.

Cheers
-Pierre

> --
> You received this message because you are subscribed to the Google Groups "spyder" group.
> To post to this group, send email to spyd...@googlegroups.com.
> To unsubscribe from this group, send email to spyderlib+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/spyderlib?hl=en.
>

Joes Staal

unread,
Apr 16, 2012, 6:04:07 AM4/16/12
to spyd...@googlegroups.com
What would it take to support python 3? Numpy, scipy and  matplotlib all can use python 3. Is it 'only' running 2to3 on all sources or are there more intrinsic difficulties for getting spyder running with python 3?

Cheers,

Joes

Joes Staal

unread,
Apr 16, 2012, 6:06:31 AM4/16/12
to spyd...@googlegroups.com
What would it take to support python 3? All scientific libraries (numpy, scipy, matplotlib) now support python 3. Is it 'only' running 2to3 on the sources or is more intrinsic work needed on spyder to support python 3?

Cheers,

Joes

Pierre Raybaut

unread,
Apr 16, 2012, 8:39:58 AM4/16/12
to spyd...@googlegroups.com
AFAIK, this is not a difficult job and there is no sticking point:
it's just a question of time.

So basically, this is 'only' a matter of:
1. running 2to3 on all sources
2. doing all the changes that the 2to3 tool can't do automatically
3. testing, testing, testing...

-Pierre

> --
> You received this message because you are subscribed to the Google Groups
> "spyder" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/spyderlib/-/fqID4ngGUecJ.

Joes Staal

unread,
Apr 16, 2012, 8:42:44 AM4/16/12
to spyd...@googlegroups.com
Hi Pierre,

I assume there is an extensive set of unit tests? I might give it a
try in a couple of weeks (very busy at the moment).

Cheers,

Joes

Pierre Raybaut

unread,
Apr 16, 2012, 9:05:14 AM4/16/12
to spyd...@googlegroups.com
There are tests yes, as many as needed to debug Spyder features and
with a modular structure, but there is not an extensive set of unit
tests (spyderlib is mainly implementing GUIs and there is no such
thing as test completeness for this kind of code, AFAIK).

-Pierre

Brandon Parsons

unread,
Apr 29, 2012, 10:12:01 PM4/29/12
to spyder
OK. So, I cloned a copy locally, ran 2to3, and started making fixes
for the remaining stuff that prevented it from even running. At this
point, 'light' mode seems to work OK, but there are occasional crashes
in the full mode, sometimes behavior depends on whether --chowconsole
or -d are used, as to how long it runs.

Several of the changes made after running 2to3 can probably just be
added to the trunk, regardless of Python version, and would help for
any future porting effort. Others may prove trickier and might require
the addition of some code to have slightly different behavior in
Python 2 vs Python 3. At any rate, one thing I wanted to ask was what
the minimum Python version Spyder supports (or will support in coming
releases), as that may have an impact on how some of the
incompatibilities would be dealt with.

I didn't do any work to add the automatic running of 2to3 in the build/
install process. I ran 2to3 on a branch, committed that, and then
worked from there to get it running. Hopefully most of the commits
after that can be added back into the mainline version, and enable
adding 2to3 to part of the build process, so as to allow Python3 work
without really hindering present development.

Should I make a clone in the google code space, and push commits there
for review/inclusion into mainline so that we can get closer to Python
3 support with 2to3?

Some of the changes I made were with regard to strings (legacy vs.
unicode), and they may not be entirely correct. This is one aspect
that will probably take some more thought to enable Python 3 using
2to3 as part of the build process.

Oh, one other thing. I need to check if any crashing problems stem
from sys.std(err|in|out) usage when using pythonw on Windows. I found
some similar issues with IPython on Windows with Python 3. sys.std*
are None when using pythonw from Python 3, so anything that counts on
them being something else (builtins are fine, since they silently
ignore those streams when they're none). Details at http://bugs.python.org/issue1415,
if interested.

Brandon

On Apr 16, 6:39 am, Pierre Raybaut <pierre.rayb...@gmail.com> wrote:
> AFAIK, this is not a difficult job and there is no sticking point:
> it's just a question of time.
>
> So basically, this is 'only' a matter of:
> 1. running 2to3 on all sources
> 2. doing all the changes that the 2to3 tool can't do automatically
> 3. testing, testing, testing...
>
> -Pierre
>

David

unread,
May 7, 2012, 10:17:13 PM5/7/12
to spyd...@googlegroups.com
Hello Brandon,

Thanks for doing this work, spyder is one of my favourite tools and I wouldn't think about moving to python 3 without it!

I was just checking out the guidelines for porting to python 3: http://wiki.python.org/moin/PortingPythonToPy3k

It seems that you are taking approach 3 from this document - creating a separate code branch for python 3 code. However, I imagine that this would add a significant development burden to spyder, as any change would have to be made to both versions.

In principal approach 1 looks really appealing - there is one code base in python 2.x, which is written in such a way that it will generate correct 3.x code when run through the 2to3 tool. So the idea would be to modify the python 2.x code until it converts nicely. I was just wondering if there are any show-stoppers which prevent you from taking this approach. I don't want to tell you what to do, but I guess it's worth thinking this over before you commit too much time and effort.

cheers
David
> > spyderlib+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages