Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: pipe_drivers
-
Labels:None
-
Team:External
Description
Nate Lust reports the following error when running coaddDriver.py:
Invoked with: <lsst.afw.image.tanWcs.TanWcs object at 0x7f0aafa3ace0>, Point2I(0, 0)
|
Traceback (most recent call last):
|
File "/software/lsstsw/stack/Linux64/ctrl_pool/13.0-6-gf96f8ec+26/python/lsst/ctrl/pool/pool.py", line 113, in wrapper
|
return func(*args, **kwargs)
|
File "/software/lsstsw/stack/Linux64/ctrl_pool/13.0-6-gf96f8ec+26/python/lsst/ctrl/pool/pool.py", line 237, in wrapper
|
return func(*args, **kwargs)
|
File "/software/lsstsw/stack/Linux64/ctrl_pool/13.0-6-gf96f8ec+26/python/lsst/ctrl/pool/pool.py", line 817, in reduceNoBalance
|
return self._reduceQueue(context, reducer, func, list(zip(range(num), dataList)), *args, **kwargs)
|
File "/software/lsstsw/stack/Linux64/ctrl_pool/13.0-6-gf96f8ec+26/python/lsst/ctrl/pool/pool.py", line 570, in _reduceQueue
|
resultList = [func(self._getCache(context, i), data, *args, **kwargs) for i, data in queue]
|
File "/software/lsstsw/stack/Linux64/pipe_drivers/13.0-18-g223e391/python/lsst/pipe/drivers/coaddDriver.py", line 221, in checkTract
|
for coord in box.getCorners()])
|
TypeError: pixelToSky(): incompatible function arguments. The following argument types are supported:
|
1. (self: lsst.afw.image.wcs.wcs.Wcs, arg0: float, arg1: float) -> lsst.afw.coord._coord.Coord
|
2. (self: lsst.afw.image.wcs.wcs.Wcs, arg0: lsst.afw.geom.coordinates.coordinates.Point2D) -> lsst.afw.coord._coord.Coord
|
3. (self: lsst.afw.image.wcs.wcs.Wcs, arg0: float, arg1: float, arg2: lsst.afw.geom.angle.angle.Angle, arg3: lsst.afw.geom.angle.angle.Angle) -> None
|
This is fallout from DM-11332 (where the selection interface was changed slightly).
Attachments
Issue Links
Activity
I thought the coding standard recommended against lambdas. I have no problem with the solution of you are comfortable with that. I also have no problem with a full function inside the other. Whatever you would like.
You're right — PEP8 says:
Always use a def statement instead of an assignment statement that binds a lambda expression directly to an identifier.
Yes:
def f(x): return 2*xNo:
f = lambda x: 2*xThe first form means that the name of the resulting function object is specifically 'f' instead of the generic '<lambda>'. This is more useful for tracebacks and string representations in general. The use of the assignment statement eliminates the sole benefit a lambda expression can offer over an explicit def statement (i.e. that it can be embedded inside a larger expression)
Fixed and merged to master. Thanks!
Paul Price
added a comment - You're right — PEP8 says:
Always use a def statement instead of an assignment statement that binds a lambda expression directly to an identifier.
Yes:
def f(x): return 2*x
No:
f = lambda x: 2*x
The first form means that the name of the resulting function object is specifically 'f' instead of the generic '<lambda>'. This is more useful for tracebacks and string representations in general. The use of the assignment statement eliminates the sole benefit a lambda expression can offer over an explicit def statement (i.e. that it can be embedded inside a larger expression)
Fixed and merged to master. Thanks! 
Nate Lust, would you mind reviewing this, please?