-
-
Notifications
You must be signed in to change notification settings - Fork 400
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
base: main
Are you sure you want to change the base?
Conversation
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-11 13:20:35 UTC |
Codecov ReportAttention: Patch coverage is
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. |
There was a problem hiding this 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
astroquery/eso/core.py
Outdated
|
||
__doctest_skip__ = ['EsoClass.*'] | ||
|
||
def decorator_with_params(dec): |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
astroquery/eso/core.py
Outdated
self._collection_list = list(res) | ||
return self._collection_list | ||
|
||
def _query_instrument_or_collection(self, query_on: QueryOnField, instmnt_or_clctn_name, *, column_filters={}, |
There was a problem hiding this comment.
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 {}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, thanks! 👍
astroquery/eso/core.py
Outdated
USE_DEV_TAP = True | ||
|
||
@staticmethod | ||
def tap_url(): |
There was a problem hiding this comment.
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
astroquery/eso/core.py
Outdated
|
||
def __init__(self): | ||
super().__init__() | ||
self._instrument_list = None | ||
self._survey_list = None | ||
self._collection_list = None |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 ;)
astroquery/eso/core.py
Outdated
@@ -305,6 +175,24 @@ def _get_auth_header(self) -> Dict[str, str]: | |||
else: | |||
return {} | |||
|
|||
def _query_tap_service(self, query_str: str): |
There was a problem hiding this comment.
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") |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
astroquery/eso/core.py
Outdated
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): |
There was a problem hiding this comment.
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
astroquery/eso/core.py
Outdated
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" | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. 👍
Addresses #3138
Changes:
list_surveyslist_collectionsquery_surveysquery_collections*_surveys(...)
in favor of_*collections(...)