Skip to content

[WIP]feat: code upgrades/streamlining from python 3.10 => 3.11 #1211

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

richardgreg
Copy link
Contributor

@richardgreg richardgreg commented May 8, 2025

What was wrong?

There is a need to explore changes from Python 3.10 => 3.11 that might affect the repo or are potentially interesting for improving code quality.

Fixes #1167

How was it fixed?

Went through each feature outlined in #1167 and implemented changes wherever necessary to improve the code

PEP 673 – Self Type:

  • Replaced TypeVar-based return annotations with typing.Self in:
    • finite_field.py (Field, PrimeField, GaloisField protocols/classes)
    • elliptic_curve.py (EllipticCurve class methods)
  • Simplified type hints for methods returning class instances

PEP 654 – Exception Groups and except*:

  • Due to the lack of parallel execution and batch validation by the EVM, it doesn't seem necessary to implement PEP 654

PEP 678 – Enriching Exceptions with Notes:

  • Most error messages seem to be properly logged, and adding notes doesn't seem to offer noticable value

dataclasses:

enum:

hashlib.file_digest:

logging.getLevelNamesMapping:

re Atomic grouping and possessive quantifiers:

string:

shutil.rmtree:

time.sleep:

typing:

python/cpython#90881

python/cpython#57684

Cute Animal Picture

Put a link to a cute animal picture inside the parenthesis-->

* Replaced TypeVar-based return annotations with `typing.Self` in:
  - `finite_field.py` (Field, PrimeField, GaloisField protocols/classes)
  - `elliptic_curve.py` (EllipticCurve class methods)
* Simplified type hints for methods returning class instances
@richardgreg
Copy link
Contributor Author

@SamWilsn, you can check this one out. I've taken a new approach to fixing #1167. I'll bundle every change in one PR. You can review each commit I make because it represents each feature, so it might not get overwhelming.

Also, when do you think it will be merged after completion? I'm asking because several PRS I opened before never got merged, even though they were seemingly approved. Are there other specific conditions related to timelines for merging PRs?

@richardgreg richardgreg changed the title feat: code upgrades/streamlining from python 3.10 => 3.11 [WIP]feat: code upgrades/streamlining from python 3.10 => 3.11 May 9, 2025
@richardgreg
Copy link
Contributor Author

Just a friendly reminder, @SamWilsn, regarding my original comment.

Secondly, I see that changes are being pushed to the files I'm working on. Since this could be an extensive PR and conflicts from the core maintainers are bound to arise, would you advise me to break the changes down into individual PRS? I'd appreciate a resolution because I am serious about making contributions that get merged 😊🙏

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.

Investigate code upgrades/streamlining for python 3.10 => 3.11 upgrade
1 participant