Let's Discuss the Matter Further

The first half of 2026

Mon, 29 Jun 2026 00:00:00 -0400

ven though my open source projects are only one hobby among several, I was able to invest enough hours over the first half of 2026 to produce several updates and releases. In case anyone is curious about what I’ve been up to, here are the milestones that were reached over the past few months.

January

The first month of the year saw a new release of my flagship astronomy library, Skyfield version 1.54.

This new version is the product of a refactoring that I started working on in 2025. Whenever Skyfield is asked to compute an .apparent() position, it figures out how much the target’s light is deflected by the Sun, Jupiter, and Saturn. And for observers on the Earth’s surface or in Earth orbit, it computes the deflection from the Earth’s mass itself. But what if a user wants to add additional deflectors to that list? Or to remove one or two of them? Or to turn deflection all the way off?

The list of deflectors, alas, was hard-coded in Skyfield’s internals as a hidden implementation detail. That needed to change! So I have now rewritten the deflection logic to turn it inside out, surfacing the list of deflectors as an optional argument to .apparent() that the caller can see and control.

The rewrite also accidentally fixed a bug in Skyfield that I hadn’t previously identified: Skyfield was sometimes incorrectly computing the slight deflection produced by the Earth’s mass. So, with this release, an occasional inaccuracy of up to 0.5 mas was eliminated for observers on the Earth’s surface and in Earth orbit.

I also released a new version 2.24 of the Skyfield support library jplephem because NumPy has decided to stop supporting assignment to an array’s .shape attribute, and so jplephem’s use of that maneuver was starting to annoy users with deprecation warnings. The library now uses NumPy’s .reshape() instead.

February

There are still folks out there who use my PyEphem astronomy library. The ephem module that it offers, despite its clunky interface, has provided the Python language with access to a basic C-language astronomy library since PyEphem’s first release in 1998.

So when a user notified me that Python 3.14 had been released, it was time for me to slog into the project’s GitHub Actions, get the build working for the new Python version, and make a release.

(But, alas, don’t look for the release in the changelog on the PyEphem web site. It turns out that the Sphinx documentation build for PyEphem is broken because of breaking changes in Sphinx itself, in setuptools, and in jinja2. Hopefully I’ll get it fixed later this year.)

March

For half a decade I have been the custodian of the XEphem astronomy application for Unix and Mac, after the retirement of its original author and maintainer, Elwood Downey.

In January the XEphem community received the news that Elwood’s long and productive life had reached its end, which inspired me, over Feburary and early March, to dig into XEphem’s open issues on GitHub and make progress on some of the bugs and issues that folks had run into. It also emboldened me — I suppose because only now do I feel that I’m really captain of the ship — to make a first big change of my own: the arrow keys can now be used to scroll around on the main Sky View showing the stars and planets.

If you’re curious to see all of the updates that were included in the new release, click “Change log” in the left-hand menu at the project’s web site.

April–June

My main focus in the second quarter of the year was wrangling a series of pull requests from a generous contributor, Clément Robert, that led to a new version 2.26 of the sgp4 library, which computes the positions of Earth satellites. The library is used both by Skyfield and by other Python projects that need satellite positions. Thanks Clément’s work, the module is now built atop the “Python Limited API”, allowing a single binary wheel to support multiple versions of Python.

Thanks to Clément’s code tweaks and metadata updates, users will hopefully no longer need to open a new issue every time a major Python version is released, asking for a new release of sgp4. Instead, the existing binary wheel will continue working even as they make new releases of Python.

I wasn’t at PyCon this year

I didn’t attend PyCon 2026, in Long Beach, California, this year.

If any readers turn out to be seriously curious as to why, then I’ll need to set aside some time to sit down and engage in some introspection and writing. But here are a few quick thoughts:

My habit of annual week-long Grand Canyon hikes has been starting to expand into three and even, sometimes, four weeks of outdoor adventures each year, which leaves less time for conferences.
I first attended PyCon, way back in 2008, not just to listen, but in order to contribute my first conference talk. Every year since then, I’ve either been a speaker myself, or else I’ve been gathering ideas for upcoming talks at other conferences that have invited me. But it feels a bit like my era has passed — invitations to conferences no longer appear in my inbox, and even if I did get an invite today, I’m not sure I’d have anything new to say. I get all kinds of fun things done with Python each month, but I accomplish them using the same approach to programming that’s served me well for a couple of decades.
Because of the collapse of my social media presence — I never did recover the kind of community that I enjoyed with other programmers when we were all on Twitter back in the late twenty-teens — I feel like I leave vibrant conversations at PyCon only to walk out into a world of silence. When I attended PyCon last year, in 2025, the conversations made my mind spark with ideas and new directions for my projects! But after a few weeks in the silence back at home, the sparks had gone out.
It was easier to say “yes” to attending PyCon when it was either at a wonderful outdoor destination (Portland; Salt Lake City) or a city that was within driving distance (Cleveland; Pittsburgh). For whatever reason, Long Beach just didn’t feel like a can’t-miss conference destination for me.

As wider context, I should mention that computer programming is not, at the moment, my day job: I paused my career a few years ago when I purchased a historic home. I assured my wife that it would only take me about a year to renovate, but, alas — it turns out that programming projects aren’t the only projects that I’m able to vastly underestimate! In case you want to follow along, here’s the project on Instagram:

https://www.instagram.com/goshens.harper.house/

While I’m enjoying all of the new technical skills that I’m learning — I’ve even started attending a monthly meetup for folks who rehabilitate historic homes — I’ll admit to having conflicting emotions about the project: doing work on a historic home doesn’t scale. My hours of work only affect and improve this one single property. Whereas, when I used to work full-time on software, dozens or hundreds of people were able to benefit from every tweak or improvement that I made.

Maybe I’ll find myself shifting myself back to a majority-keyboard schedule within the next year or two? We’ll see!

What’s Next?

So what will I focus on as we begin the second half of 2026? With the sgp4 release now complete, I feel like it’s time to take a deep breath and regroup.

Over the next month, I want to read back through all open GitHub issues for my various projects, and make sure they all have up-to-date responses. Sometimes I intend to reply at length about a complicated issue, but don’t get around to it before needing to respond to a more pressing bug.

I might also finally abandon setuptools for my compiled projects. A few experiments that I did last week suggest that, for compiled Python modules like sgp4 and ephem, meson-python might result in a better workflow both locally on my laptop and also in CI — for example, by not writing build products directly into the source tree. Hopefully the attempt to switch build tools doesn’t become a yak-shaving ordeal that prevents me from making other progress on my projects!

Finally, I think I’m going to tackle a small example Skyfield project: a script that computes a year’s worth of celestial events — like New Moon and Full Moon, solstices, equinoxes, and conjunctions — and writes out an .ics iCalendar file that the user can import into their favorite calendar program. I’ll publish it as an example in the Skyfield docs. It should be fun. Over the years, I have spent so much time maintaining my various projects that I’ve often not had any time to actually use them!

Animating Ptolemy’s Equant with Python, SVG, and CSS

Fri, 23 Aug 2019 00:00:00 -0400

[UPDATE: A full Solar System model is now available that you can view, animated using the techniques described in this post! See Ptolemy’s cosmos, to scale.]

You will recall my previous blog post that tried to build the necessary scaffolding for me to finally write up my 2017 PyCon Ireland keynote on the structure of the Medieval universe. It ran into several problems with matplotlib animations — but, having written that post, I realized that the problem ran deeper.

How could any animation show a Solar System, when a Solar System’s motion never exactly repeats? The orbital periods of the planets aren’t exact multiples of each other, and don’t provide a moment when the planets reach their original positions and the animation can start over again. At whatever moment an animation finished and looped back to the beginning, the planets would visibly and jarringly jump back to their original position.

But then I remembered that modern browsers support animation directly, and thought: could a python script produce an SVG diagram with a separate CSS animation for each planet, that repeated each time that specific planet finished a revolution?

The result would be an animated Solar System that fits into a few thousand bytes, would render with perfect clarity, and runs continuously for as long has the viewer was willing to watch!

But there’s a problem.

The CSS animation mechanism is perfect for the simplest possible planetary orbit: uniform circular motion. Here’s a simple SVG diagram in which a planet and the line connecting it to the origin are grouped within a single <g> element.

%pylab inline
from IPython.display import HTML
𝜏 = 2.0 * pi

circular_svg = '''
<svg version="1.1" width=220 height=220>
 <g transform="translate(110, 110)">
  <circle cx=0 cy=0 r=100 stroke=lightgray stroke-width=1 fill=none />
  <g class="anim %s">
   <line x1=0 y1=0 x2=100 y2=0 stroke=lightgray />
   <circle cx=100 cy=0 r=5 fill=#bb0 />
  </g>
  <circle cx=0 cy=0 r=3 fill=#040 />
 </g>
</svg>
'''

HTML(circular_svg % 'stationary')

Populating the interactive namespace from numpy and matplotlib

We use translate() to move (0,0) to the middle of the diagram where it can serve as the circle’s center. We paint a big circle for the orbit, small circles to mark the orbit’s center and a planet, and a line to link them.

Read the full article...

Animating Saturn with matplotlib, a subclass, and mock.patch()

Sat, 04 Aug 2018 00:00:00 -0400

em>Based on my lightning talk at PyOhio 2018

I hope that this comes across not as a complaint about matplotlib, but as a celebration of tools that a dynamic language like Python offers in situations where a library is seriously misbehaving and needs some crucial live-edits to run successfully.

The task had seemed so simple. To support an upcoming series of posts based on my 2014 keynote at PyCon Ireland (“Building the Medieval Universe in 7 Easy Steps with Scientific Python”), I wanted to render an animation of one of the outer planets — I chose Saturn — progressing slowly eastward across the sky over several seasons and several years.

Instead, I got to spend a weekend wrestling with matplotlib.

Read the full article...

Learning SymPy while eliminating trigonometry from rotations

Sat, 16 Jun 2018 00:00:00 -0400

I have played with Python’s SymPy symbolic math library before, but for the first time last week I used it to solve a real problem! In the process I had to confront three errors in my understanding of how SymPy works:

I had somehow imagined that SymPy was secretly storing all the equations I was writing and would use them automatically later.
I thought I could convince SymPy to eliminate intermediate symbols.
I thought each variable in my problem needed to be a SymPy symbol.

While working through these misunderstandings to a solution, I ran across two features that made SymPy’s results easier to use in my Python code than I had expected!

SymPy not only supports fancy formatting of math formulae, but can print them as pure Python expressions ready to be pasted into a Python program.
SymPy can perform subexpression elimination to prevent your code from computing any sub-result twice.

The sections of this post tackle each of the items above in turn.

Read the full article...

Computing a final Tiangong-1 pass with Python

Sat, 31 Mar 2018 00:00:00 -0400

Do you remember the thrilling re-entry scene at the end of the movie Gravity? The Chinese space station Tiangong-1 is orbiting at thousands of miles per hour when (spoiler) it dips fatally into the Earth's upper atmosphere. The drag buffets and tears at the station’s components before the increasing friction finally flashes the air around the station into a glowing plasma, reducing the station to a shredded sparkling field of debris.

Well — tomorrow, it’s actually going to happen.

But before it does, I’d love to see Tiangong-1 from the ground as it makes its final orbits above our planet. Can Python help me find a final pass of Tiangong-1 over my town?

Let’s give it a try!

Read the full article...

A New Driver for the Original Twiddler

Fri, 30 Mar 2018 00:00:00 -0400

The practical take-away from this post is that if you’re ever trying to debug serial communications with a device that — against all tradition — only transmits when the Data Terminal Ready line is clear (devices should normally do the opposite: transmit only when Data Terminal Ready is set), then never run stty on the serial port to double-check your settings.

Why?

Because stty turns Data Terminal Ready back on. Without even asking you!

So the device will never communicate with you, and you may very nearly conclude that your device is broken before you happen to remove the stty call and see the device finally work. So that’s the take-away. But the full story is a bit longer.

Read the full article...

Fixing OpenConnect’s VPN Search Domains on Ubuntu

Thu, 03 Aug 2017 00:00:00 -0400

A quick technical note about VPN hostnames on Ubuntu Linux, since otherwise I will forget:

If other users of your VPN can refer to hosts by an unqualified hostname, but an Ubuntu user like you receives a not found error for the same hostname, then try creating the following file (you will need to create the directory by hand).

Read the full article...

PyCon Trivia Night, Third Edition

Thu, 09 Jun 2016 00:00:00 -0400

At PyCon 2016 it was my honor, for a third year in a row, to host a Trivia Dinner on the first evening of the conference! This year’s venue was the storied Crystal Ballroom, a music venue in Downtown Portland’s west end. To make sure that our event took full advantage of the big stage, I booked the Adventure Capitalists, who followed up the trivia dinner with a rousing set of punk startup tunes:

Have a conference pass? Come by the Crystal Ballroom and see the Adventure Capitalists! pic.twitter.com/sg0GxqiDpF
— PyCon (@pycon) May 31, 2016

Last year’s trivia night questions focused on such exciting topics as PEP-8 and Python 3, but it turns out that these were fraught topics about which most of the audience were not very familiar. So I made a promise: the PyCon 2016 trivia night would be all Python 2, all the time! The questions below dive into and celebrate the retro roots of the legacy Python language.

Read the full article...

PyCon Trivia Night, Second Edition

Thu, 16 Apr 2015 00:00:00 -0400

As was the case during first year that the conference was in Montréal, I was invited for PyCon 2015 to lead an evening dinner trivia contest on the first full conference day.

Wanting to help the audience celebrate all of the advances that are being made in Python 3, I skewed my questions heavily in the direction of the strides that the core developers are taking with the new version of the language. Alas! My focus was not as popular with the audience as I had hoped. It turns out that Python 2.7 is still far more popular than its predecessor, and many contestants were frustrated about being asked so many questions and details about a language hardly anybody used. So I made a promise to the audience: if a third trivia dinner happens at PyCon 2016 in Portland, that I will make it Retro Python Trivia Night and ask all of the questions about the Python 2 series!

The questions follow, then the answers are way down at the bottom of the post so you can try answering on your own before you scroll down and peek. Enjoy!

Read the full article...

The First-Ever PyCon Trivia Night

Tue, 29 Apr 2014 00:00:00 -0400

PyCon seems to find new ways of fostering community single every year. This year’s conference in Montréal featured the début of official Friday night dinners which I first learned about from a surprising email entitled Want to MC a trivia night at the PyCon dinner?

I accepted the invitation!

While I have enjoyed other volunteer roles at PyCon, this one was particularly exciting because of the difference that official evening activities can make for newcomers. Remembering my own first conferences, it can be stressful to face that lonely moment when the evening lightning talks have just finished. Everyone else seems to pair up and make dinner plans so quickly. Unless you can somehow involve yourself in someone else’s dinner plans, you picture a long walk back to your hotel to order room service — alone — while everyone else sits at candlelit tables in real restaurants talking and laughing and enjoying Québécois cuisine. I hope that my dinner, plus the one hosted by Greg Brockman, provided a few people with a safe default option who otherwise might have had to fend for themselves.

Read the full article...