Update deprecated Python 3.8 typing

[hmellor]

The main change is in pyproject.toml, the rest is just fixing the pre-commit errors that creates.

The following two rules have been enabled:

• https://docs.astral.sh/ruff/rules/non-pep585-annotation/
• https://docs.astral.sh/ruff/rules/deprecated-import/

They have been enabled:

• Outside of the vllm/ directory
• Inside vllm/v1 and vllm/entrypoints
• For the direct children vllm/*.py

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

🚀

[youkaichao]

i think this is not necessary. we should keep the compatibility if it does not hurt.
for example, if someone still uses a fork of vllm, and he sticks to python 3.8, this PR will make their rebase and update very painful.

[DarkLight1337]

Python 3.8 is effectively not supported anymore (even without this PR) as we now directly subscript builtins like list, dict in multiple places in vLLM.

[youkaichao]

Python 3.8 is effectively not supported anymore (even without this PR) as we now directly subscript builtins like list, dict in multiple places in vLLM.

I think it's fine to use new type annotation like list directly in new code, but i doubt the necessity to change all the existing code.

[DarkLight1337]

We can selectively enforce this rule via https://docs.astral.sh/ruff/settings/#lint_per-file-ignores

Perhaps we can start by applying this to V1 code?

[youkaichao]

We can selectively enforce this rule via docs.astral.sh/ruff/settings#lint_per-file-ignores

Perhaps we can start by applying this to V1 code?

I'm fine with applying it to new code, but I think changing thousands of lines as in this PR is not necessary.

[hmellor]

I don't think there is any harm in using the modern syntax throughout vLLM.

I'm in favour of updating everything because then the whole repo is consistent and little consistencies like these add up to make the library more maintainable.

[hmellor]

if someone still uses a fork of vllm, and he sticks to python 3.8

Also, PyTorch has dropped Python 3.8 and we already use the modern syntax in some places. So as @DarkLight1337 said, we already do not support Python 3.8.

[NickLucche]

For what is worth torch still appears to be using the old List syntax in the codebase for one.

[cjackal]

If one cares about a thousand git blame noise for type hint update, how about adding a .git-blame-ignore-revs?

[hmellor]

For what is worth torch still appears to be using the old List syntax in the codebase for one.

I imagine the effort required to make that change in PyTorch would be too large. In vLLM it wasn't too bad (and I've already done the work).

If one cares about a thousand git blame noise for type hint update, how about adding a .git-blame-ignore-revs?

@youkaichao what do you think of @cjackal's suggestion?

[DarkLight1337]

I think there is no need to ignore the git blame, since the number of lines changed is honestly not that much compared to the total number of lines in the file. I would only consider this for formatting changes.

[youkaichao]

For what is worth torch still appears to be using the old List syntax in the codebase for one.

I imagine the effort required to make that change in PyTorch would be too large. In vLLM it wasn't too bad (and I've already done the work).

If one cares about a thousand git blame noise for type hint update, how about adding a .git-blame-ignore-revs?

@youkaichao what do you think of @cjackal's suggestion?

I'm not talking about git-blame , I'm talking about people merge and rebase upstream in their fork. changing type annotation gives no significant benefit in my opinion, but will make some users' life worse since they have more merge conflicts.

[simon-mo]

I think we can limit this to new code (v1), private code (tests), and constantly evolving code (examples, entrypoints).

As we start the full V1 integration and code removal process, eventually all the code will be new in 1.0.0

[hmellor]

How's this?

I have reverted everything inside vllm/vllm except:

• v1
• entrypoints
• Python files that are direct children of vllm

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @hmellor.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[DarkLight1337]

This sounds good to me. Let's merge this over the weekend to avoid conflicts.