python 3.2 PyOS_ascii_strtod

[oystercatcher]

I am on fedora 15 and just installed python3, python3-devel the version in python 3.2 also downloaded
ephem 3.7.3.4 and installed using python3 setup.py install. After going into python3 import math, ephem
and get error

[pstan@logarithm f15-doc]$ python3
Python 3.2 (r32:88445, Feb 21 2011, 21:11:06)
[GCC 4.6.0 20110212 (Red Hat 4.6.0-0.7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math, ephem
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.2/site-packages/ephem/__init__.py", line 5, in <module>
    import ephem._libastro as _libastro
ImportError: /usr/lib64/python3.2/site-packages/ephem/_libastro.cpython-32mu.so: undefined symbol: PyOS_ascii_strtod
>>>

I see that in python 3.2 it is deprecated

[Brandon Rhodes (brandon-rhodes)]

It has obviously been too long since I have touched the Python 3 version of PyEphem! I will try to look at this by the first week of May.

[oystercatcher (pystanis)]

I was looking through the libastro source and I find occurences of PyOS_ascii_strtod in only two files.
format.c and misc.c

I replaced it with PyOS_string_to_double adding NULL as the third parameter then ran
python3 setup.py install
Now when I run in the python3 shell import ephem there is no immediate error but my scripts fail
with an value error . So no progress made on my part but still hoping that ephem will soon run in python3.

[Brandon Rhodes (brandon-rhodes)]

The PyOS_ascii_strtod() call is often returning complete nonsense. After six hours of wrestling with this bug, I have removed the call to PyOS_ascii_strtod() and replaced it with an entirely self-contained routine for parsing floats, and the program STILL crashes on me and goes haywire. Unless I have made some terrible blunder between the working code branch that powers the Python 2 version and the branch that powers Python 3, there must be some difference between the Python versions that exposes or exercises some terrible and obscure bug in my code (or XEphem's). I am not sure what to try next, as I have no guess as to where the problem lies — with my malloc() and free()? With a stray pointer somewhere? With function lifetimes and pointers to variables on the stack?

In other news, I have started experimenting with writing a pure-Python implementation of the logic inside of libastro. If all goes well, I might be able to switch to shipping only Python. Then, people who need speed could use PyPy; while normal people would still get at least reasonable performance, but with an error like this one — an obscure, hours-long wade into machine code behavior — never possible again. :)

Meanwhile, let me know if you have any ideas. This one has me stumped! Running "python3.2 -m unittest ephem.tests.test_bodies" completely freezes on my machine and has to be killed.

[oystercatcher (pystanis)]

I appreciate your efforts and for your reply. It seems that I have miscommunicated something.
Having used pyephem (albeit naively) before python3, I was curious when you made the
announcement for the new source. Up until python3.2 the source code would compile.
So my first notice of a problem was with python3.2.

The error states that PyOS_ascii_strtod is deprecated and looking
through the online doc for python3.2 the function should be replaced
by PyOS_string_to_double(,,)

grepped your source and replaced the function. compiled pyephem in python3.2
and opening python3, I was able to import the module.

Mr Rhodes, I am not a programmer, and I barely get the python code
you developed. So if I am going over ground you already covered,
please forgive me.

perhaps the earlier version of the function has problems hence deprecated
When I try to run some input to the modified pyephem, I get a value error
which leads me to think that I just need to pass the function something
it understands. which apparently I dont.

If I can figure out the PyOS_string_to_double function, I might get
some code to run, I'll let you know if I do

patrick

[Yichao Yu (yuyichao)]

I have tried the newest version in the repo and did the same replacement (by adding a define in setup.py actually) along with some other tweak (wrong version number in setup.py etc.) and managed to get it compiled.

AFAIK there is a `ValueError: cannot convert string to float` when I first trying to do sth with a ephem.Date but it will be fine afterwards!!!!

>>> d = ephem.Date('1970/1/1 00:00')
>>> str(d)
ValueError: could not convert string to float:
>>> str(d)
'1970/1/1 00:00:00'

I'm trying to dirty hack this problem by catching all unexpected exceptions and try again and it (kind of) works for now.

Hope to see a out of box working version for py3k. thx

[Brandon Rhodes (brandon-rhodes)]

I have finally solved the problem by making a several-hour search for an alternative strtod implementation we could use, and finally finding one here:

http://www.netlib.org/fp/dtoa.c

I have just released a new version of the "ephem" package that includes this change:

http://pypi.python.org/pypi/ephem/

At long last, this should get PyEphem working again for people whose Python 3 version is recent enough that it has deprecated and removed the essential string-to-float function we were using! Please try it out and let me know it if works. If not, then please open a bug on GitHub, where I am now hosting the project:

https://github.com/brandon-rhodes/pyephem/issues?state=open

Thanks, everyone, for letting me know about this problem, even though it took me on a long journey to get it fixed—I guess I should not have left the obvious solution, of abandoning libc and Python's library entirely, as my last option!

[oystercatcher (pystanis)]

I have been testing the python3 ephem code although somewhat delayed from the announcement of the fix.
Fedora python versions as of f15 (I am now on f17) are problematic for either python2 or python3 as
both python versions have deprecated PyOS_ascii_strtod

The python version on my f17 system is python3 -V 3.2.3
I am using a compiled version of xephem to compare the output version 3.7.6-rc4

My interest in using pyephem is for celestial navigation and related math problems
Initial testing looks good