PyEphem now available for Python 3.0!

Date:

13 December 2008

Tags:

computing, pyephem, python

Eager not to be left behind by the advance of history,
I have released PyEphem
tonight for Python 3.0!
After updating its C-language routines earlier this week,
as described
in my previous post,
and adjusting its Python syntax,
I thought that my work was done —
until I received a bug report from Reto Schüttel,
an enterprising Swiss programmer.
He had read my previous post,
asked me for the location of PyEphem's Python 3.0
branch,
downloaded it with bzr,
and already tried it out, not only on his Linux machine,
but also on his OS X machine!

While the first
twenty revisions of my branch deal with simple Python 3.0 mechanics,
I must congratulate Mr. Schüttel
for most of the improvements in the subsequent
dozen revisions.
We not only exchanged emails all day
as I produced one revision after another
that I needed him to test,
but he then joined me on IRC tonight until 3:30am in his time zone
as we worked out the last problems.

The issues were all related to localization under OS X.
The astronomy library underlying PyEphem used the C-language functions
sscanf() and atof()
to turn strings into numbers,
and it turns out that these functions are very sensitive to locale
under the specific combination of OS X and Python 3.0!
Because of his locale,
the functions wanted a comma instead of a period
to separate whole numbers from their decimal fraction
(so that π would have to be input like 3,141
rather than like 3.141).
They also wanted month name abbreviations
to be in German rather than English,
ruining my test cases
that check planet positions against
Naval Observatory tables
which use English month abbreviations
like Jan, Feb, and Mar
with very little regard for how the months would be spelled in German.
We are still mystified by the combination of Python version
and operation system that were necessary to cause this problem:

To work around this problem,
I discovered a wonderful PyOS_ascii_strtod() function
in Python's C library that avoided all of the problems
that I was having with localization,
and so I gradually rewrote the astronomy routines
to use that function instead.
Fixing the problems with month names was easier;
instead of trying to make Python convert month abbreviations
by passing the '%b' conversion character
to time.strptime(),
I simply converted months to integers myself
and then passed the integers in
with the simpler '%m' format character.
It was only late at night
that we finally tracked down every routine that was misbehaving.

The final puzzle was how to release my new software.
The Python Package Index
does not yet allow a project to offer separate source code archives
for both the Python 2.x and the 3.0 version of a project.
There might be some clever way
of storing both versions of the source code
in the same .tar.gz file,
but the packages I see on PyPI that already support both 2.x and 3.0
contain enough #ifdef statements
to convince me that I want to keep my branches separate!

I was saved by a peculiarity of my project.
Though it provides the Python package named ephem,
the actual project on PyPI
has always been named “PyEphem” instead.
The product has to have the “Py” in front, you see,
to distinguish it
both from the original text-screen ephem command
and the modern
XEphem
graphical application,
and my first instinct had been to name the project after the product.
But as I gained experience with PyPI,
it seemed more and more awkward
that programmers who wanted their programs to be able to:

importephem

had to remember to type something different when installing:

easy_installpyephem

Since I had been wanting to switch PyPI names anyway,
I suddenly saw my chance!
I have now released the new Python 3.0 version of PyEphem
under
the actual package name ephem
and will continue to maintain the 2.x version of the package
separately under
the old pyephem
name.
Obviously,
this solution only works because of my project's unique circumstances;
I have no idea what other projects should do
who also want to come out with their new Python 3.0 versions
this weekend.

Fans of PyEphem should rest assured
that when I develop new features,
I will be adding them to both versions
of PyEphem for probably at least the next decade.
I have absolutely no intention of abandoning or slowing development
of the Python 2.x version of the library;
I simply wanted the library available to users of the new platform.
As always,
feel free to email me with bugs, suggestions, and new features —
and, enjoy using PyEphem and Python!