These are chat archives for astropy/astropy
@adrn when you say
there is a lot of magic that is probably better not understood for the time being…
do you mean that it’s too complicated to explain why it’s a bad idea to subclass?
git commit, then
git rebase --continue, but now i'm getting the following error:
`Applying: Added skeleton source code (core.py); Modified index.rst.
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".`
SkyCoordinitializer dealing with parsing inputs and it might be a headache to figure out how to pull out things specific to
Target(since we will probably want to accept new kwarg options)
git add, then do
git rebase --continue
SkyCoorddoes not? Because based on the API right now, the answer is: nothing.
FixedTarget(ra, dec).coord.rais more explicit about what it’s grabbing an RA from than
FixedTargetsubclass to the appropriate Astropy module rather than creating something mostly redundant in astroplan?
About the need for a
Target class: I think it is worth having a class for exactly the properties you mention -- e.g., name, magnitudes, epoch, ephemerides, and possibly more features that we may add down the line. We could also add convenience methods for making plots (like airmass curves).
About subclassing: A
Target has a coordinate, but a
Target is not a coordinate. Most relevant here are discussions about object composition vs. inheritance -- I'm arguing for composition. Here are some links to discussions about the differences:
(I can only vouch for the stackoverflow link, but the others look nice)
Another specific example of why I think composition is a better idea: a
MovingTarget (or whatever name), e.g., an asteroid, should not inherit from
SkyCoord, which represent a single place at a specific time.
First off, I would write:
c = SkyCoord(ra=ra, dec=dec, frame='icrs') targ = FixedTarget(coord=c, ...more stuff)
(e.g., don't allow passing
dec in to the initializer)
But then yea, the coordinate stuff is self-contained in a
.coordinates?) attribute, e.g. if you really need the RA:
.coordsince coordinates is the name of a module.
get_methods in the coding guidelines -- would it be useful to link you to articles / discuss that concept? Using properties instead of setters/getters is definitely a Python cultural preference and, again, could be subjective
astropy/testsdir, and I want to do a relative import to get
core.py. How should I write that? The absolute_import option has me confused
ValueError: Attempted relative import in non-package
astroplan |-- __init__.py |-- core.py |-- tests | |-- __init__.py | |-- test_whatever.py
from .. import coreshould work -- how are you running the
python setup.py testor are you trying to run the script directly via
python setup.py test, which runs all of the tests by calling them in package style, e.g., roughly by calling
python setup.py test will run all of the tests -- you probably just want to run tests in that particular module, or maybe even a subset of the tests in that module. You can use command line args to filter which tests to run. Imagine in my
test_whatever.py module, I have 2 tests: one called
test_stuff and one called
test_more_stuff. I can run:
python setup.py test -t astroplan/tests/test_whatever.py
to run all tests in that module, or
python setup.py test -t astroplan/tests/test_whatever.py --args="-k stuff"
to run all tests that contain the word
python setup.py test -t astroplan/tests/test_whatever.py --args="-k more_stuff"
to just run the test called
astroplanso I don't think there will be any path clashes!