Setting stretch as a string is problematic if the stretch requires a parameter about astrowidgets HOT 5 OPEN

👎 on disallowing string for Ginga though. I don't see the point to have to manually build an astropy.visualization object when I can just pass in a string to it.

Agree, even for things other than Ginga. Almost all of the astropy stretches have defaults for optional parameters, so something like https://github.com/astropy/astrowidgets/pull/142/files#diff-6aea2ce078dbeb19a51bdb4018c2b963ffa8728ce163c5d91aeb3bf42a3a2293R337 works as long as users can change properties after the fact.

from astrowidgets.

Actually, the original implementation called for an Astropy stretch to be the value, I think it was turned into a string to get ginga working quickly, maybe?

from astrowidgets.

After looking this over some more I think it makes sense to go with 3....or maybe even disallow strings.

from astrowidgets.

I see in #126 that there is no restriction imposed on what stretch can be. It might be nice to be explicit about what is allowed, though.

from astrowidgets.

2 and 3 are basically the same solution, but just a matter of preferring method over attribute setter, or vice versa.

👎 on disallowing string for Ginga though. I don't see the point to have to manually build an astropy.visualization object when I can just pass in a string to it.

from astrowidgets.