v2.0.0 Release Plan

[Apricot-S]

• [Feature Proposal] Change instance methods to static methods #74
• Change the use of class variables to instance variables to resolve issues in free-threaded builds #84
• [Proposal] Improve type safety with potential Pydantic adoption #90
• [Feature Proposal] Migrate dict return types to TypedDict #103
• [Proposal] Update Ruff Configuration to select = ["ALL"] and Establish a Step‑by‑Step Refactoring Strategy #104
• [Feature Proposal] Stricter Validation for Meld Detection Functions (is_chi / is_kan / is_pair) #105
• Remove deprecated attributes #108
• [Feature Proposal] Add Shanten.TENPAI_STATE = 0 #109
• [Feature Proposal] Convert Yaku into an abstract base class (ABC) #110
• [Feature Proposal] Make Yaku.yaku_id a required field #111
• [Task] Decide whether Yaku.name should be required #112
• Yaku class improvements
  • Fix type error in is_condition_met() in subclass implementations
• Refactor code to resolve existing mypy type errors
• Refactor unit tests
  • Split multiple asserts into separate parameterized tests
  • Add missing test cases
• Drop support for Python 3.9, which reached its EOL in October 2025
• Split the example into use cases
• Wiki for v2
  • Replace the link to the repository in the v1 Wiki with a link tagged with v1.4.0
• API documentation (Sphinx)

[Nihisil]

I'm thinking about whether we should add the pydantic dependency to the project to have typed inputs and outputs. It will hurt performance a bit, but it will make using the library much easier. I have not made a decision on this yet, as it involves a lot of work, but maybe I will find time for that improvement. What are your thoughts on this?

[Apricot-S]

Personally, I consider the fact that this library has zero external dependencies to be one of its characteristics.
For introducing types, I was thinking of using TypedDict.

On the other hand, if the library is used via an API, I agree that introducing type safety with pydantic could be very beneficial.

@Nihisil
Do you envision using pydantic models also for inputs and outputs,
or would its usage be limited to internal implementation only?

[Apricot-S]

Reference: Serialization & Validation Library Benchmarks
https://jcristharif.com/msgspec/benchmarks.html

[Nihisil]

Do you envision using pydantic models also for inputs and outputs

Yes, that was my plan, but I am still not sure since, as you mentioned, library without external dependencies can be a good characteristic for a lib

[Apricot-S]

@Nihisil

I’ve listed all the improvement ideas and tasks that came to mind so far, and some of them have already been merged into the master branch. However, the current list is still unrefined, and I believe this is a good moment to review the scope and priorities together.

I would like to ask for your input on the following two points:

1. Could you share your thoughts on which proposals should be included, excluded, or adjusted for v2.0.0?
   Some tasks may not be necessary, or might be better suited for a later release.
   If there are additional items we should consider, your guidance would be very helpful.

2. Would you be open to converting this Issue into a milestone to better organize the v2.0.0 work?
   I believe milestone-based tracking could make the overall plan clearer and help contributors understand where they can get involved.
   If we proceed with a milestone, I’d also like to discuss the appropriate level of granularity.

Whenever you have time, I’d appreciate your feedback. Thank you as always.

[Nihisil]

All listed points look good for v2. You can send me the list of the ones you are less interested in, and I can handle them to help with the 2.0.0 release.

Also, I created the 2.0.0 milestone and added you as a maintainer for the repo (thank you for your efforts in this repository!). You should be able to manage issues and milestones now, let me know if this is not working