issue_comments

Thanks @lusewell and @spencerkclark

Unfortunately we don't do backports.

Thanks for catching that additional spot.

Its only a performance issue to attempt to import cftime repeatedly. Having it fail once in the top level import is not a big problem.

Yes, understood. I just prefer that we are consistent across the code base -- either we use this pattern only where absolutely necessary or we use it everywhere. In light of that do you mind introducing this pattern in times.py as well? There are two places where cftime is imported within functions there too:

https://github.com/pydata/xarray/blob/7bfee3eaa8fd731494cf6b406d6abb4bec061001/xarray/coding/times.py#L167

https://github.com/pydata/xarray/blob/7bfee3eaa8fd731494cf6b406d6abb4bec061001/xarray/coding/times.py#L417

I think we don't have to worry about the tests, because they already follow this pattern to an extent; in building the requires_cftime decorator, a cftime import is only attempted once.

After that, just fix the linting error and add a what's new entry, and I think this should be ready to go from my perspective.

doesn't look like it?

But in both cases we always check for the existence of cftime via import cftime, so if python is clever enough to remember that cftime doesn't exist the second time it's asked to import it, then where is the opportunity for speedup?

Hopefully @lusewell can enlighten us :sweat_smile:

I guess it always tries importing if the module doesn't exist and so that's a slowdown?

Thanks for the suggestion @lusewell .

I'm a bit confused as to how exactly this improves performance though - you've moved the location of the import cftime statement to the top of the file, but I was under the impression that python doesn't ever import a module more than once, because after the first time it's a fast hash lookup. So surely in both cases we only look for the existence of cftime once? Perhaps I've misunderstood though?