Skip to content

Conversation

@jrappen
Copy link
Collaborator

@jrappen jrappen commented Nov 1, 2025

No description provided.

@jrappen jrappen changed the title [CSS] minor fixes for python code [CSS] upgrade to py3.13 Nov 1, 2025
@deathaxe

This comment was marked as resolved.

@@ -1 +1 @@
3.8
3.13
Copy link
Collaborator

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?

Copy link
Collaborator

@FichteFoll FichteFoll Nov 2, 2025

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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:
Copy link
Collaborator

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).

@michaelblyons
Copy link
Collaborator

Force-pushing a new squashed commit every time makes reviewing more difficult.

@FichteFoll
Copy link
Collaborator

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.

@jrappen jrappen marked this pull request as draft November 3, 2025 11:04
@jrappen
Copy link
Collaborator Author

jrappen commented Nov 5, 2025

I'll fix the left-overs tonight, thanks for the feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants