Skip to content

Ordering of leap second update can lead to import warnings #9490

@mhvk

Description

@mhvk

After #9365 was merged, @taldcroft noticed that "In a clean build of master right now I'm seeing this:"

In [1]: from astropy.io import ascii
WARNING: leap-second auto-update failed due to the following exception: ImportError("cannot import name 'convert_numpy'",) [astropy.time.core]

???

Clearly, import order is important in ways it shouldn't be. I'll investigate but suggestions would be most welcome...

EDIT: reason it is tricky: many of the most common time formats need an up-to-date leap-second table (e.g., Time.now() uses TimeDatetime, which, like TimeISO* calls erfa.dtf2d, which needs leap second information. But the LeapSecond class subclasses QTable, so needs to import astropy.table. Table itself only imports Time locally, so is safe, but some parts of io.ascii import Time on top and therefore are not.

Possible solutions:

  1. Make LeapSeconds a class independent of Table - which means also moving it out of iers. That means parsing the files outside of io.ascii and having very IERS-like configuration elsewhere; this seems a horrible duplication of work.
  2. Ensure Time is imported only locally in io. But it seems rather annoying not to be able to count on being able to import such a fundamental class.
  3. Ensure erfa is imported only locally in Time, iers, etc., and move the update back there. More than a little annoying, since used a lot in time.formats. Also, is a very basic package that should just be importable (and is not currently causing the problems).
  4. Ensure the leap-second update is only done on first use of Time.

Option (4) may be the best. Should I do this with something in Time.__new__?

cc @taldcroft, @eteq

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions