resolve_object should accept integers

[snbianco]

Bugfix so that the utils.resolve_object function also accepts integers or iterables containing integers for the objectname parameter. This is especially relevant for TIC IDs, K2 IDs, etc. Also added new test cases.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.54%. Comparing base (aaa6e53) to head (34df3ca).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3435   +/-   ##
=======================================
  Coverage   70.54%   70.54%           
=======================================
  Files         232      232           
  Lines       20022    20023    +1     
=======================================
+ Hits        14125    14126    +1     
  Misses       5897     5897           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bsipocz]

Was this a bug or a feature, isn't it reasonable to assume one feeds in strings for these?

[snbianco]

This was actually brought to my attention because of a lightkurve issue. Previously, you could input an integer directly and have it be resolved if it was within a certain range of TIC/KID IDs.

[bsipocz]

I believe that should be dealt with inside light curve, for here it feels wrong. I mean why just TIC/KID id then, why not panstarrs object IDs or any other surveys that have a numerical ID?

cc @keflavich if he wants to chime in

[keflavich]

My take is that this is a lightkurv issue, specifically:

--> 182 object_names = [objectname] if isinstance(objectname, str) else list(objectname)

is type checking. Probably this is a case where a property check is more appropriate, e.g.

try:
    object_names = list(objectname)
except TypeError:
    object_names = [objectname]

I agree with @bsipocz that this is not a good approach to include in astroquery: object IDs are database-specific, and it looks like the implementation proposed here already creates a dangerous ambiguity, i.e., is it a TIC ID or a K2 ID?

We can be overridden here if MAST has a clear, specific need to support integer ID based queries, but I'd recommend that it not be built in to resolve_object and certainly should not be applied generally to other modules.