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

Python 3.12.3 #219

Closed
wants to merge 3 commits into from
Closed

Python 3.12.3 #219

wants to merge 3 commits into from

Conversation

FeodorFitsner
Copy link

@FeodorFitsner FeodorFitsner commented May 10, 2024

Changes in this PR:

  • Python version bumped to 3.12.3
  • Patch updated to work with 3.12.3.

The only thing I haven't figured out is how to remove "hints" after line numbers:

image
  • AppleFrameworkFinder extended to support frameworks in the format Frameworks/{module.name}.framework/{module.name} which is required to work with podspec and closer to how it's implemented in Python 3.13.

PR Checklist:

  • All new features have been tested
  • All new features have been documented
  • I have read the CONTRIBUTING.md file
  • I will abide by the code of conduct

@freakboy3742
Copy link
Member

Thanks for the contribution; however, while I appreciate the enthusiasm, I'm going to close this PR without merging.

As a result of the finalisation of PEP 730, there are some major changes that need to be made to this repository. You can see some initial progress on this work in #191; that branch needs to be brought up to date with the final state of CPython 3.13.0b1, finalised, and the changes that have been landed upstream need to be backported to 3.9-3.12 (3.8 will be omitted because it will be deprecated in October this year, at the same time we add 3.13 support). A partial backport of some of those changes will only make the final merge task harder.

Unfortunately, this sort of maintenance update is an area where community contribution doesn't actually help lower the overall workload for us as maintainers. There are a series of large PRs that need to be backported; if we do the backports ourselves, we know how they have been generated, and can have confidence that they work (and haven't inadvertently introduced bugs). If the contribution comes from the community, they effectively have to be reviewed in as much detail as if they had been developed from scratch. This is true even if they are the result of a direct backport, because it isn't trivial to verify that a patch is an unmodified back port, and hasn't introduced inadvertent bugs - or worse, malicious changes. To be clear - I don't suspect you of doing anything malicious here, but if the recent XZ issues have revealed anything, it's that you can't be too careful, especially when dealing with complex changes.

As a guide for the future - if you're planning to spend effort developing large changes, it's worth checking with the maintainers first to see if those changes are desirable, or would be helpful. In this case, I could have warned you before you spent the time developing this PR that backport help isn't actually helpful in this case.

@FeodorFitsner
Copy link
Author

Totally understood, no worries! I really appreciate what you're guys going. Looking forward to see the new support packages mechanism implemented!

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.

None yet

2 participants