DM-10765: Replace existing WCS classes with SkyWcs #40
Conversation
r-owen
force-pushed
the
tickets/DM-10765
branch
from
e3bc176
to
c912b49
Compare
| @@ -30,7 +30,8 @@ | |||
| import sys | |||
|
|
|||
| import lsst.daf.base as dafBase | |||
| import lsst.afw.image as afwImage | |||
| from lsst.afw.fits import readMetadata | |||
| from lsst.afw.geom import makeSkyWcs | |||
| import lsst.skypix as skypix | |||
There was a problem hiding this comment.
If there's no specific reason not to, I do prefer import ... as ... (as opposed to from ... import ...) so that it is more obvious where the function comes from when used far away from the import statements. Ditto for all other instances in other packages...
There was a problem hiding this comment.
I hear you and I used to feel that way myself. However, I now strongly prefer to import symbols when only one or two are used, especially if I the names are unambiguous. This allows me to avoid the controversial use of namespace abbreviations or avoid spelling out the full library name prefix every time the symbol is used. If namespace abbreviations were not controversial I'd be happier to use them. But even that adds characters that can obscure the code, and spelling out the full namespace is worse in that way and often results in extra line wraps.
I think this partly comes from getting used to how C++ handles namespaces. In any case it's clearly a matter of taste, and since both are allowed, I'm afraid I'm going to continue importing the symbols. I agree it can get out of hand (afw test_skyWcs.py, alas) and you should feel free to complain if you find instances that have.
| @@ -26,6 +26,7 @@ | |||
| import unittest | |||
|
|
|||
| import lsst.afw.image | |||
| from lsst.afw.geom import SkyWcs | |||
No description provided.