Remove **kwargs from queue

[freddyaboulton]

Description

Don't think removing kwargs is a breaking change because we were already not allowing arbitrary kwargs. Removing them from the signature has the benefit of having your editor warn you before you run your code and reducing code for us. Also treat concurrency_count as a warning instead of an error.

🎯 PRs Should Target Issues

Before your create a PR, please check to see if there is an existing issue for this change. If not, please create an issue before you create this PR, unless the fix is very small.

Not adhering to this guideline will result in the PR being closed.

Tests

1. PRs will only be merged if tests pass on CI. To run the tests locally, please set up your Gradio environment locally and run the tests: bash scripts/run_all_tests.sh

2. You may need to run the linters: bash scripts/format_backend.sh and bash scripts/format_frontend.sh

[gradio-pr-bot]

🪼 branch checks and previews

•	Name	Status	URL
	Spaces	ready!	Spaces preview
	Website	ready!	Website preview
	Storybook	ready!	Storybook preview
	Visual tests	all good!	Build review
🦄	Changes	detected!	Details

---

Install Gradio from this PR

pip install https://gradio-builds.s3.amazonaws.com/425695d93556daa847a461f7938157867570c511/gradio-4.0.2-py3-none-any.whl

Install Gradio Python Client from this PR

pip install "gradio-client @ git+https://github.com/gradio-app/gradio@425695d93556daa847a461f7938157867570c511#subdirectory=client/python"

[gradio-pr-bot]

🦄 change detected

This Pull Request includes changes to the following packages.

Package	Version
gradio	minor

• Maintainers can select this checkbox to manually select packages to update.

With the following changelog entry.

Remove **kwargs from queue

Maintainers or the PR author can modify the PR title to modify this entry.

Something isn't right?

• Maintainers can change the version label to modify the version bump.
• If the bot has failed to detect any changes, or if this pull request needs to update multiple packages to different versions or requires a more comprehensive changelog entry, maintainers can update the changelog file directly.

[aliabid94]

Why not raise an exception if we no longer support concurrency count? We deprecated it moving into 4.0. I think it's a good way to force old apps to think where they want to set their concurrency limits instead.

[freddyaboulton]

You want to keep in signature but raise an error instead of warning? Happy to but main branch is using a deprecation warning so I thought the intention is to warn.

[aliabid94]

You want to keep in signature but raise an error instead of warning?

I removed it from the signature because it was being deprecated, but I added **kwargs so that if an 3.x user tried to use it, they got a specific error telling them it was deprecated. (DeprecationWarning is an exception type, not a warning, despite its name).

I feel like that's a proper deprecation compared to keeping it in the signature and it being ignored.

[freddyaboulton]

All warnings are exception classes but the convention is to call via warnings.warn in my opinion. I don't feel strongly about it though I can add that part back.

I don't want us to add back **kwargs though. I think its nicer if you get visual feedback that a parameter is not allowed before you run the code as opposed to having to run your code and then get an error.

[pngwn]

It isn't deprecated if it is gone. A deprecation indicates that the thing still works but that it isn't recommended/ optimal/ may be removed in the future.

I think this would be a ValueError or something.

[aliabid94]

I don't have a strong opinion either, but

I think its nicer if you get visual feedback that a parameter is not allowed before you run the code as opposed to having to run your code and then get an error

This is the logic I used for getting rid of concurrency_count from the arguments. I didn't want users to see this as a valid parameter, but I still wanted to pass a specific message for users who tried using it.

[abidlabs]

Good with this change. I agree that we should avoid **kwargs as much as possible. They make it very easy to have typos, and we lose the benefit of static typechecking of arguments. I think a DeprecationWarning is reasonable here since we are likely to remove this argument in the near future.

[freddyaboulton]

Thanks for the discussion all! Keeping the warning raise but removing kwargs.