Exposing examples as a component for Blocks

[abidlabs]

We now have gr.Examples() as a component that can be used within Blocks. See example: demo\blocks_inputs\run.py

Usage:

• Case 1: Only inputs is provided, in which case clicking on the examples will populate the inputs components

with blocks:
....
    with gr.Row() 
        textbox = gr.Textbox()
        examples = gr.Examples(examples=examples, inputs=textbox)
        ....

    button.click(predict, textbox, label)
....

• Case 2: Both inputs and outputs as well as the prediction fn is provided (required for cache_examples=True), in which case, if the examples are cached, clicking on the examples will populate the inputs components and the output components.

with blocks:
....
    with gr.Row() 
        textbox = gr.Textbox()
        examples = gr.Examples(examples=examples, inputs=textbox, outputs=label, fn=predict, cache_examples=True)
        ....

    button.click(predict, textbox, label)
....

This approach is more wordy than the one proposed by @radames in #1156 but I think more logical since it ties the examples clearly to the input (and potentially the output components). Open to feedback here.

Original API proposed by @radames:

with blocks:
....
    with gr.Row() 
        examples = gr.Examples(examples=examples, cache_examples=False)

    button.click(predict, inputs, outputs, examples)
....

• Problem: in this approach, what would happen if multiple event triggers are passed the same examples?

Closes: #1156

Note: This PR also does a lot of other cleanups in the Interface class. A lot of the bloat is removed because we now only accept single functions in the fn parameter of Interface. I've tested a bunch of demos and they work fine, but would appreciate a careful review to make sure I didn't miss anything!

[radames]

hi @abidlabs ,

Your proposal approach looks good to me. It's also enables users to create multiple examples for different predict functions on the same screen, right? For example, this Space has two sections, and would benefit of separated examples for each step.

with blocks:
....
    with gr.Row() 
        textbox = gr.Textbox()
        outbox =  gr.Textbox()
        examples = gr.Examples(examples=examples, inputs=textbox, outputs=outbox, fn=predict, cache_examples=True)
        ....
    with gr.Row() 
        data = gr.DataFrame()
        examples2 = gr.Examples(examples=examples2, inputs=outbox, outputs=data, fn=predict2, cache_examples=True)
        ....

    button.click(predict, textbox, label)
.... 

[abidlabs]

Yes, that is now possible @radames. See example here: demo\blocks_inputs\run.py

[freddyaboulton]

@abidlabs This is awesome! Taking a closer look now but one thing that stood out to me is that we're giving lots of power to the user and that increases the chance of misusing examples. I wonder if we should invest some time in making sure incorrect combinations of parameters are caught and informative error messages are displayed.

For example,

• when you set cache_examples to True but don't provide a fn you get a TypeError: 'NoneType' object is not callable error.

    gr.Examples(
        examples=[os.path.join(os.path.dirname(__file__), "lion.jpg")],
        inputs=im,
        outputs=im_2,
        cache_examples=True)

• when you provide inputs, fn but not outputs and cache_examples is True:

    gr.Examples(
        examples=[os.path.join(os.path.dirname(__file__), "lion.jpg")],
        inputs=im,
        fn=mirror,
        cache_examples=True)

• If the size of the examples list doesn't match the api of the fn you get a IndexError: list index out of range

    gr.Examples([["hi"], ["hello", "Eve"]], [txt, txt_2], txt_3, combine, cache_examples=True)

• There's a weird bug when examples is None that I commented below.

Some of these may be rare cases and not worth catching in the library but some may be worth guiding the user on. Curious what your thoughts on the matter are.

[freddyaboulton]

The examples don't change during the lifetime of the app. I think we can compute processed_examples once and avoid a bunch of repetitive work?

[abidlabs]

This is awesome @freddyaboulton! Agree with you about catching and throwing errors. Will add those in and fix up Series.

[abidlabs]

Series should be fixed now, thanks for the suggestion @freddyaboulton!

[freddyaboulton]

@abidlabs Thank you for making the changes! This looks good to me. Just a minor comment on the parameter validation logic you added.

[freddyaboulton]

This doesn't work as expected since outputs gets wrapped into a list so passing None will get converted to [None] which is not None. I think we should move this up to before outputs gets wrapped into a list or change the check to outputs[0] is None.

[abidlabs]

Ah good catch thanks!

[abidlabs]

Thanks for the thorough feedback @freddyaboulton!