Started updating demos to use the new gradio.components syntax#848
Conversation
- default -> default_value refactoring
- refactor output types into output_type and make them auto
- all events are implemented
- refactor fn: str -> Callable
- add change event to TabItem
| import gradio.inputs as inputs | ||
| import gradio.outputs as outputs | ||
| from gradio.blocks import Blocks, Column, Row, TabItem, Tabs | ||
| from gradio.components import ( |
There was a problem hiding this comment.
@abidlabs are you sure about this? I think it is more proper to import components from gr.components. I am against importing all the components in the init. There are many components and a single component is not a critical element of gradio library, they need to referenced from gr.components
If people want to have shorter references they can import specific components via
from gradio.components import Textbox, Json...
There was a problem hiding this comment.
Hmm I really think the components and layouts both should be very easily imported since they are fundamental to building blocks. For me, gr.Textbox is a lot friendlier than gr.components.Textbox.
There are basically 3 ways to make it friendly that I considered.
- Doing
from gradio.components import Textbox, Image...- the problem with this is that you have to explicitly import every component, which is annoying. Plus some of the components have common names (likeImage), which could conflict with other classes in other common libraries (likefrom PIL import Image) - Doing
from gradio.components import *- bad practice, plus the same conflict issue - Making the components accessible as
gr.Textbox, etc. I think this is way to go. The only potential problem is that if we have conflicts within thegr.namespace, which is unlikely.
There was a problem hiding this comment.
Well I still think the same, might hear thoughts from @aliabid94 and @pngwn if it will help.
There was a problem hiding this comment.
We need to be able to support gr.Checkbox() or gr.Textbox(). It is way too much extra typing to have to include gr.components every single time. This is how streamlit does it as well. There are tradeoffs to be made between user-friendliness and proper explicitness in building APIs and gradio definitely needs to lean towards user-friendliness.
| import pkg_resources | ||
|
|
||
| import gradio.components as components | ||
| import gradio.inputs as inputs |
There was a problem hiding this comment.
Why did you remove these? It makes gradio.inputs components unreachable from ide and user. They can import but cannot go to implementation.
There was a problem hiding this comment.
To be honest, I don't understand the effects of these lines. I thought importing a class in __init__.py just makes it accessible under gradio. namespace. But inputs and components are already accessible as gradio.inputs and gradio.components?
But if it is causing issues in your IDE, I can bring them back
There was a problem hiding this comment.
Yeah let's bring them back, this is what happens when we miss them:
- Remove KeyValues from components
- Resolve Components imports in inputs and outputs
- fix default parameter usage in demos
- fix default parameter usage in demos
- fix default parameter usage in demos
- docstring updates
- tweaks
- add change event to Tabs
Blocks components V2
Blocks-Backend-Events
Build interfaces from blocks Co-authored-by: Ali Abid <aliabid94@gmail.com>
|
Note: I've changed the non-keyword argument for the gr.Radio(["add", "subtract", "multiply", "divide"]) |
abidlabs
changed the title
gradio.components syntaxgradio.components syntax
|
Ok so I've just gone through the first 2 demos so far (and created 2 of my own). But opening this PR for review now so that it doesn't get too big! |
|
LGTM. What's the purpose of write_config.py? |
Thanks. @pngwn needs it for setting up integration tests |
3 participants
demos/folder to use the newgradio.componentsimports and syntaxBlocks