search

nanograv / PINT

PINT is not TEMPO3 -- Software for high-precision pulsar timing
Other
118 stars 101 forks source link

Running pint with python3 #45

Closed nategarver-daniels closed 7 years ago

nategarver-daniels commented 9 years ago

I've run into a few issues with PINT relative to python3, mostly print() type issues and a few others. I was also having a hard time with PySPICE and python3, even though it should theoretically work. I found a possible replacement, written by a student at UVA called spiceypy. Seems to be fairly drop in. I've been running through the example notebook and making changes as necessary. Would you like me to fork the repo and try to make the changes in such a way that "import blargh from future" will let things work with python2.7?

paulray commented 9 years ago

I do everything in python 2.7, so my top priority is that. However, we all agreed it would be good to write code that was 2.7 and 3 compatible. There is a wiki page that describes how we try to do that: https://github.com/nanograv/PINT/wiki/Python-Compatibility I'm not sure about the version statements on that page, however. Why does it say "2.6 or older", for example? Surely we want to support either 2.6 and 2.7 or maybe only 2.7. I can't see PINT supporting anything earlier than 2.6.

So, any changes that improve 3.x compatibility without hurting 2.7 compatibility should be good. Specifically, adding the from future import print_function, division etc. are all good to do.

I'm not familiar with the "blargh" module, though. :-)

PySPICE has been a source of some aggravation for a while, so investigating options is worth doing. You might post a link to spicepy. A quick Google didn't seem to find it.

nategarver-daniels commented 9 years ago

Thanks Paul. We're trying to write all of our new nanograv data manipulation stuff in python3, operating on the theory that over the lifetime of the PTA project python2 will mostly go away. The PySPICE replacement that I found is https://github.com/AndrewAnnex/SpiceyPy.

matteobachetti commented 9 years ago

How about pyephem? It had been discussed as ephemeris package for Astropy Matteo

On 20:32, Wed, Aug 19, 2015 nanograv-pire notifications@github.com wrote:

Thanks Paul. We're trying to write all of our new nanograv data manipulation stuff in python3, operating on the theory that over the lifetime of the PTA project python2 will mostly go away. The PySPICE replacement that I found is https://github.com/AndrewAnnex/SpiceyPy.

— Reply to this email directly or view it on GitHub https://github.com/nanograv/PINT/issues/45#issuecomment-132734503.

paulray commented 9 years ago

Yeah, someone should do a comparison of PySPICE alternatives for ease of installation, use, and correctness and present a recommendation at a PINT telecon.

paulray commented 9 years ago

I just glanced at pyephem and it is based on XEphem, which uses VSOP87 and some other sources as its ephemeris. For PINT, I think we would be better off with a solution based on JPL SPICE since that can use any of the more modern JPL ephemerides. I don't think VSOP87 can meet a 1 ns accuracy goal.

matteobachetti commented 9 years ago

Sorry, I meant jplephem: https://github.com/brandon-rhodes/python-jplephem It does support SPICE.

On Wed, Aug 19, 2015 at 9:03 PM, Paul Ray notifications@github.com wrote:

I just glanced at pyephem and it is based on XEphem, which uses VSOP87 and some other sources as its ephemeris. For PINT, I think we would be better off with a solution based on JPL SPICE since that can use any of the more modern JPL ephemerides. I don't think VSOP87 can meet a 1 ns accuracy goal.

— Reply to this email directly or view it on GitHub https://github.com/nanograv/PINT/issues/45#issuecomment-132743985.

Matteo Bachetti

www.matteobachetti.it

"I would love to change the world, but they won't give me the source code"

paulray commented 7 years ago

So, now PySPICE has been removed, in favor of jplephem. I think we should update the Python compatibility page to say 2.7 and 3.5 or higher. Then, I think we should get the travis-ci tests working for 3.5 and then close this issue. I know @cdeil has been working on this. Does anyone think PINT needs to support Python 2.6?

cdeil commented 7 years ago

+1 to drop Python 2.6 (many scientific Python packages did already or are doing it now), unless you have several people asking for it.

Also matching the statement what you support to what's tested on travis-ci is a good idea. Supporting Python 3.4 would probably be zero extra work, but again, I would only do it if you have someone asking for it.

As far as I know there's two problematic things in PINT that prevent tests from running on Python 3 (and also with pytest). I don't have time to try to come up with a fix before the Christmas break. But if you think it helps, I could file separate issues pointing out the problem, in case someone else has time to look at this?

cdeil commented 7 years ago

I think the main remaining issue for Python 3 is #218 . (at least that's where running the tests with Python 3 currently fails)