-
Notifications
You must be signed in to change notification settings - Fork 597
[CSS] upgrade to py3.13 #4368
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
base: master
Are you sure you want to change the base?
[CSS] upgrade to py3.13 #4368
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
| @@ -1 +1 @@ | |||
| 3.8 | |||
| 3.13 | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ST 4201+ reads 3.8 as 3.13. Why not just leaving those files alone until py33 is removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having them say 3.8 when the files actually require 3.13 is just wrong, though, even when ST 4201+ can handle it. This should also prevent issues when trying to run these Python files in an older ST build that does not have the 3.13 runtime.
I would be in favor of just removing them, if they are not required, but the 3.3 host is not dead yet and still the default, afaik.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need typing in such simple plugins and beyond that the modules and this set of PRs doesn't add anything which judges breaking things for users which probably use cloned repos - at least not until public betas are available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typing annotations are basically free, assuming you stick to the various Python version requirements for various features. I would certainly not be against adding them if they don't break anything, e.g. if they were compatible with 3.8. If we're doing strict upgrades to 3.13 syntax (and without from __future__ import annotations), then I agree with you that breaking compatibility just for the heck of it isn't really worthwhile.
Either way, the .python-version should reflect the actually required Python version or be removed, imo.
|
|
||
| @cached_property | ||
| def func_args(self): | ||
| def func_args(self) -> dict: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to also have the dict generics here (and below).
|
Force-pushing a new squashed commit every time makes reviewing more difficult. |
|
In general, I would decide whether to squash/rebase a PR on a case-by-case basis, but since we squash all PRs on this repo anyway, avoiding force-pushes is really the better workflow here. |
|
I'll fix the left-overs tonight, thanks for the feedback. |
No description provided.