Add support for Annotated type about magicgui HOT 5 CLOSED

implemented in #43 ...@magicgui(arg={'min': 10, 'max': 100}) will continue to be the "promoted" API... but arg: Annotated[int, {'min': 10, 'max': 100}] = 50 will also work. moreover, the magicgui.signature.MagicParameter is a subclass of inspect.Parameter that bundles the widget options in an Annotated type in the Parameter.annotation

from magicgui.

also want to bring this https://github.com/napari/magicgui/issues/20#issuecomment-648530931 from @jni into this thread...

@tlambert03: am I correct in gathering then that pretty much everything we're already doing with argument-specific and Qt-specific options could be easily added as Annotated types?

@jni: They could, but to be honest I don't think they should. Those Qt-specific options and switching between valid widgets for a given type, and fiddling with widget rather than argument parameters should be part of the magicgui API, rather than the function signature. But something like narrowing down a type is a perfect use of Annotated imho.

@jni, what do you think? I'm not proposing that this would be the only way to provide options in the magicgui API (arguments to the decorator would still be supported), more just "if an Annotated type is used, we'll parse the __metadata__ field for options". One additional thing I'm thinking here is that in #33, I'm kinda considering making the primary internal object that gets passed around in magicgui an inspect.Signature object. That pretty much encapsulates everything I need to build a gui (parameter name, default value, & type) ... so additional parameter-specific options on the type annotation seems natural internally, and might as well be exposed for those wanting to use it in function signatures?

from magicgui.

Good thinking using this for default slider ranges.

I made the suggestion a few minutes after I first encountered the Annotated type. And while I still think it is potentially a great way to address some problems in magicgui.

However (and I realize I am contradicting myself here) I also feel it is a bit odd to work with annotations to type annotations as it feels like a meta-meta level. As an alternative to the example above, maybe it would be cleaner to have a range class, as in a numerical type with associated min/max values.

Then again, I can think of many widgets that could implement an int selection, i.e. a text box, a range slider, a dial etc. Some of those need a range, others don't. I guess if the Annotated annotation contains range limits as you show above it would default to some kind of range slider, otherwise to a text box.

from magicgui.

@tlambert03

I'm not proposing that this would be the only way to provide options in the magicgui API

I would go further though: this should be the fallback way to do this, while kwargs to magicgui should be the recommended way. In these scenarios I typically aim for the library/decorator/wrapper (in this case, magicgui) to be as non intrusive as possible to the wrapped code. For example, there's no fundamental reason for the sigma parameter to gaussian filter to be limited to a particular range — we would never add minimum or maximum to its type annotation in skimage. But for Paths, it makes perfect sense to annotate a path with whether it is for reading or writing, or whether it should be a directory, and we would add that to scikit-image. That's the distinction I'm trying to make and one which I would hope magicgui would recommend...

But, sure, as a fallback, I guess it might work? 🤷

from magicgui.

this should be the fallback way to do this, while kwargs to magicgui should be the recommended way. ... That's the distinction I'm trying to make and one which I would hope magicgui would recommend...

understood and totally agree. "magicgui" will recommend that :)

I think I'm probably focusing (in my head) a bit more at the moment on the usefulness of Annotated in an inspect.Signature as the internal representation that magicgui would use to pass around this info, in which case "supporting" it here would be trivial. but I definitely agree, I wouldn't want to start changing all the examples to encourage people to use Annotated for GUI-specific things in their function signatures

from magicgui.