Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop Python 3.8 support #8685

Open
abidlabs opened this issue Jul 2, 2024 · 7 comments
Open

Drop Python 3.8 support #8685

abidlabs opened this issue Jul 2, 2024 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@abidlabs
Copy link
Member

abidlabs commented Jul 2, 2024

Given that Python 3.8 is EOL-ing in October, we can drop support for this. We can also consider ending support for 3.9 but that may be too aggressive for the 5.0 release

@abidlabs abidlabs added the enhancement New feature or request label Jul 2, 2024
@abidlabs abidlabs added this to the Gradio 5️⃣ milestone Jul 2, 2024
@abidlabs abidlabs changed the title Drop 3.8 support Drop Python 3.8 support Jul 2, 2024
@pngwn
Copy link
Member

pngwn commented Jul 3, 2024

We should drop 3.9 unless there is an exceptional reason not to. 3.10 contains some really nice typing features that would allow us to clean quite a few things up.

@abidlabs
Copy link
Member Author

abidlabs commented Jul 3, 2024

I'm not sure if its a good idea to drop support for Python 3.9 if there's still a year left and it might make Gradio 5 unusuable for many developers without having to install a new version of Python. It looks like ~10% of our users currently use Python 3.9 -- which is about the same % as Python 3.8, but at least that is being EOL'd.

image

As far as I can tell, there is only this place in the code place where we have to handle Python 3.9 or below explicitly is here:

if sys.version_info < (3, 10):

@pngwn
Copy link
Member

pngwn commented Jul 8, 2024

Hmm, i thought I responded to this.

While we don't explicitly handle versions elsewhere, there are definitely cases where we have multiple implementations to handle different versions. I definitely did this for the component docs. I didn't version sniff, but I did feature detection instead but it amounts to the same thing.

As an example, my image_slider component requires python 3.10, supporting lower version complicates the code without reason imo. I don't think asking people upgrade to a version of python that was released 3 years ago is a huge ask. As a comparison, we require node 18 in the client and that was released 1 year after python 3.10.

@abidlabs
Copy link
Member Author

abidlabs commented Jul 8, 2024

As a recent ex-Windows user, upgrading Python can be a major pain 😆 its not as simple as upgrading a library or even as simple as upgrading node versions. And it doesn't seem to be that rare either, a quick search on Spaces shows a decent number of Spaces that have set python_version to 3.9: https://huggingface.co/search/full-text?q=python_version&p=1

As an example, my image_slider component requires python 3.10, supporting lower version complicates the code without reason imo.

If supporting Python 3.9 does indeed make the code more difficult to maintain, I'd be fine with dropping support. But I'm pretty surprised to hear that. What does Python 3.9 not support for the image_slider component? Does adding from __future__ import annotations fix it?

@pngwn
Copy link
Member

pngwn commented Jul 8, 2024

Does adding from future import annotations fix it?

No, i've always had this in an dropped 3.9 support later. I'll double check what the issue was.

@abidlabs
Copy link
Member Author

abidlabs commented Jul 8, 2024

results from an informal twitter poll just for fun: https://x.com/abidlabs/status/1810321004939612295

@pngwn
Copy link
Member

pngwn commented Jul 11, 2024

34 ppl, kill it til its dead.

@abidlabs abidlabs self-assigned this Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants