Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable TAP for ESO module #3141

Draft
wants to merge 56 commits into
base: main
Choose a base branch
from
Draft

Enable TAP for ESO module #3141

wants to merge 56 commits into from

Conversation

juanmcloaiza
Copy link
Contributor

@juanmcloaiza juanmcloaiza commented Nov 28, 2024

Addresses #3138

Changes:

  • list_instruments
  • list_surveys list_collections
  • query_instruments
  • query_surveys query_collections
  • query_main
  • query_apex_quicklooks
  • deprecate functions *_surveys(...) in favor of _*collections(...)
  • Make sure that ALMA collection is handled properly

@pep8speaks
Copy link

pep8speaks commented Nov 28, 2024

Hello @juanmcloaiza! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2024-12-16 16:12:32 UTC

Copy link

codecov bot commented Nov 28, 2024

Codecov Report

Attention: Patch coverage is 46.34146% with 22 lines in your changes missing coverage. Please review.

Project coverage is 67.56%. Comparing base (50867f6) to head (da3b874).
Report is 8 commits behind head on main.

Files with missing lines Patch % Lines
astroquery/eso/core.py 46.34% 22 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3141      +/-   ##
==========================================
+ Coverage   67.53%   67.56%   +0.02%     
==========================================
  Files         233      233              
  Lines       18487    18496       +9     
==========================================
+ Hits        12486    12497      +11     
+ Misses       6001     5999       -2     

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

@bsipocz bsipocz added the eso label Nov 28, 2024
Copy link
Member

@bsipocz bsipocz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One comment for now regarding the deprecation, otherwise is looking good so far (I didn't dive into the details, but had a quick look


__doctest_skip__ = ['EsoClass.*']

def decorator_with_params(dec):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are deprecation decorators in astropy, is there a particular reason you choose not to use those?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the info, I am now using them.

self._collection_list = list(res)
return self._collection_list

def _query_instrument_or_collection(self, query_on: QueryOnField, instmnt_or_clctn_name, *, column_filters={},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mutable default arguments like [] or {} should be avoided. For such cases it's better to use None as default and initialise the mutable argument in the method, for example:
column_filters = column_filters or {}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, thanks! 👍

USE_DEV_TAP = True

@staticmethod
def tap_url():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could add a type hint for the return value


def __init__(self):
super().__init__()
self._instrument_list = None
self._survey_list = None
self._collection_list = None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe it's a matter of taste but normally we don't need to specify the type in the variable name. In this case I would use collections instead of collection_list

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since all of those are initialized to None, maybe it would make sense to annotate the types instead of having "list" in the name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original name was _survey_list. My interpretation was that "list" refers not to a data type, but rather to a concept, like "The list of the supermarket" or "list of ingredients"; in this case a "List of available instruments/collections". Thus, I only changed the "survey" --> "collection", but I don't see disadvantages of removing _list from the name. Consider it done ;)

@@ -305,6 +175,24 @@ def _get_auth_header(self) -> Dict[str, str]:
else:
return {}

def _query_tap_service(self, query_str: str):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add type hint for return type

try:
table_to_return = tap.search(query_str).to_table()
except pyvo.dal.exceptions.DALQueryError:
raise pyvo.dal.exceptions.DALQueryError(f"\n\nError executing the following query:\n\n{query_str}\n\n")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why rethrowing the same exception with a different error message? Is the original error message not clear enough? I think it's also possible to chain the original exception with a custom one but I don't remember the syntax

Copy link
Contributor Author

@juanmcloaiza juanmcloaiza Dec 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is helpful to see the query that was being executed. In that way users can test it externally (for example here: http://archive.eso.org/programmatic/#TAP) and pinpoint the source of error. I found this to be the simplest way of achieving that goal, but I'm open to suggestions, if there's a better or standard way to do it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One could wonder if this shouldn't be addressed in TAP itself -> after all TAP could return the query as part of the error message.

raise Exception(f"\n\nUnknown exception {e} while executing the following query: \n\n{query_str}\n\n")

return table_to_return

def list_instruments(self, *, cache=True):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add type hints to method signature

Comment on lines 60 to 73
class QueryOnField():
table_name = ""
column_name = ""


class QueryOnInstrument():
table_name = "dbo.raw"
column_name = "instrument"


class QueryOnCollection():
table_name = "ivoa.ObsCore"
column_name = "obs_collection"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be cleaner to have one dataclass storing table and column information and three constants with the different copnfigurations, example:

@dataclass
class QueryConfig:
  table_name: str
  column_name: str

QUERY_ON_FIELD = QueryConfig(table_name="", column_name="")
etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely, thanks! This is what I was looking for but didn't manage to remember how it was done properly. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants