[Branch]: differential_rotation

This is the feature branch that contains some diff rot code, I think it needs some love so I am opening this so people don't forget about it!!
How would a decorator handle the case when some function parameters are
required to be Quantities, and some are not?

On Wed, Nov 5, 2014 at 2:43 AM, Stuart Mumford <notifications@github.com>
wrote:

> In sunpy/image/coalignment.py:
>
> > @@ -44,6 +46,18 @@ def _default_fmap_function(data):
> >      return np.float64(data)
> >
> >
> > +def _is_pixel_unit(a):
> > +    """Tests the input to see if it is an astropy Quantity with units in
> > +    pixels."""
> > +    return (isinstance(a, u.Quantity) and a.unit == 'pix')
> > +
> > +
> > +def _is_arcsec_unit(a):
> > +    """Tests the input to see if it is an astropy Quantity with units in
> > +    arcseconds."""
> > +    return (isinstance(a, u.Quantity) and a.unit == 'arcsec')
>
> The thought did cross my mind. I was wondering about the advantages of a
> decorator over a normal function call.
> ... <#1497ee8e3c674585_>
> On 4 Nov 2014 23:53, "rhewett" <notifications@github.com> wrote: > In
> sunpy/image/coalignment.py: > > > @@ -44,6 +46,18 @@ def
> _default_fmap_function(data): > > return np.float64(data) > > > > > > +def
> _is_pixel_unit(a): > > + """Tests the input to see if it is an astropy
> Quantity with units in > > + pixels.""" > > + return (isinstance(a,
> u.Quantity) and a.unit == 'pix') > > + > > + > > +def _is_arcsec_unit(a): >
> > + """Tests the input to see if it is an astropy Quantity with units in >
> > + arcseconds.""" > > + return (isinstance(a, u.Quantity) and a.unit ==
> 'arcsec') > > Could this be handled with a decorator? > ...
> <#1497d3a87957195f_> > On Tue, Nov 4, 2014 at 4:27 PM, wafels <
> notifications@github.com> wrote: In sunpy/image/coalignment.py: > @@
> -44,6 +46,18 @@ def _default_fmap_function(data): > return np.float64(data)
> > > > +def _is_pixel_unit(a): > + """Tests the input to see if it is an
> astropy Quantity with units in > + pixels.""" > + return (isinstance(a,
> u.Quantity) and a.unit == 'pix') > + > + > +def _is_arcsec_unit(a): > +
> """Tests the input to see if it is an astropy Quantity with units in > +
> arcseconds.""" > + return (isinstance(a, u.Quantity) and a.unit ==
> 'arcsec') Informative errors are good, but as I said, this will add a lot
> more if blocks in the code: if _is_quantity(input_parameters): ....code
> that I don't think should be in an if block else: ValueError('shoulda used
> quantities') I am not sure that the added complexity in every piece of code
> is worth it. ... <#1497ceb96d8a0da6_> On Tue, Nov 4, 2014 at 5:10 PM, Stuart
> Mumford < notifications@github.com> wrote: In sunpy/image/coalignment.py:
> > @@ -44,6 +46,18 @@ def _default_fmap_function(data): > return
> np.float64(data) > > > +def _is_pixel_unit(a): > + """Tests the input to
> see if it is an astropy Quantity with units in > + pixels.""" > + return
> (isinstance(a, u.Quantity) and a.unit == 'pix') > + > + > +def
> _is_arcsec_unit(a): > + """Tests the input to see if it is an astropy
> Quantity with units in > + arcseconds.""" > + return (isinstance(a,
> u.Quantity) and a.unit == 'arcsec') I think we probably need a utility
> function for it so that it is easier to do everywhere, the thing with
> Quantities is because they are so similar to floats, also very specific,
> and new I think it is very important to give the user informative errors.
> -- Reply to this email directly or view it on GitHub <
> https://github.com/sunpy/sunpy/pull/902/files#r19840204>. -- Reply to this
> email directly or view it on GitHub <
> https://github.com/sunpy/sunpy/pull/902/files#r19841374>. -- Reply to this
> email directly or view it on GitHub <
> https://github.com/sunpy/sunpy/pull/902/files#r19846289>.
>
> --
> Reply to this email directly or view it on GitHub
> <https://github.com/sunpy/sunpy/pull/902/files#r19858731>.
>