You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During my cleaning up of astropy.vo.samp package in order to support Python 3, I discovered an issue that affects astropy/config/configuration.py. Line 140 checks the instance of a string verifying whether it is a basestring or not. However since Python 3 basestring abstract type has been removed. Actually my testing code failed with Python 3 until I didn't modify line 140 replacing basestring with str. Nonetheless I see that basestring is used in a number of files, so I don't understand how Astropy can run with Python 3 and pass all tests. Am I missing something?
Astropy uses 2to3 in the build process for Python 3, which then converts basestring to str and does a whole bunch of other stuff. The upshot is that you can't test in the source directory with Python 3, you need to use the installed version which has been fixed up by 2to3.
I think that if/when we drop Python 2.6 support we should move toward making all of Astropy's code cross-compatible and drop the 2to3 requirement (with the exception of any extern packages, which would be pre-converted, as I think is already the case).
👍 to that. I sort of consider 2to3 a stopgap measure. In my experience, running 2to3 over the source, adding from __future__ import unicode_literals, print_function, division, absolute_import and then manually tweaking a few things is a pretty efficient way to arrive at cross-compatible code.
What are the specific problems that you get with 2.6? io.ascii is (or at least was in asciitable form) compatible with 2.6 and 3.x at the source level. I think this guide is pretty good:
Activity
taldcroft commentedon Jun 21, 2013
Astropy uses
2to3in the build process for Python 3, which then convertsbasestringtostrand does a whole bunch of other stuff. The upshot is that you can't test in the source directory with Python 3, you need to use the installed version which has been fixed up by 2to3.embray commentedon Jun 25, 2013
I think that if/when we drop Python 2.6 support we should move toward making all of Astropy's code cross-compatible and drop the 2to3 requirement (with the exception of any extern packages, which would be pre-converted, as I think is already the case).
mdboom commentedon Jun 26, 2013
👍 to that. I sort of consider 2to3 a stopgap measure. In my experience, running 2to3 over the source, adding
from __future__ import unicode_literals, print_function, division, absolute_importand then manually tweaking a few things is a pretty efficient way to arrive at cross-compatible code.taldcroft commentedon Jun 28, 2013
👍 as well.
What are the specific problems that you get with 2.6?
io.asciiis (or at least was inasciitableform) compatible with 2.6 and 3.x at the source level. I think this guide is pretty good:http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
embray commentedon Jun 28, 2013
Maybe we can do this for 2.6? Apparently there are some things in there that I previously thought weren't.
Also FWIW my d2to1 project supports 2.5 through 3.3 with the same code base. That's a lot more hassle, but it's using six.py which helps.
mdboom commentedon Jul 26, 2013
Just to keep the issue list clean, I propose we close this in favor of #1219, which is starting to (bit by bit) resolve this.
astrofrog commentedon Jul 26, 2013
👍