[GSoC 2026]: Systematic Type Annotation and Type-Driven Refactoring of SymPy’s Computational Algebra Subsystem (sympy.polys)

[Vedant Dusane]

Hi everyone,

It vedant Dusane from this side. As i am contributing to sympy from last few month on one fix and important issue that will help sympy improving code safety, developer productivity, reduce future bugs, and many more. I have merged some PRs on Add type annotation. On that bases i am planning to prepare a full GSoC scope. 

I would like to propose the  project idea related to the improvement of type annotations and type safety within the "sympy.polys" system, especially within core files such as "polytools.py," "polyutils.py," etc.

Polynomials is an elementary part of the computational algebra library delivered by SymPy. Many of the library’s higher-level functions are built upon the polynomial subsystem. As I was conditioning the type annotations in "polytools.py", I saw that there are certain functions that require type information that is not available yet and uses generic types.

My proposed approach would be to:

1.  Systematically reviewing the important polynomial modules ("polytools", "polyutils", "polyclasses" and "domains")
2. Adding precise and correct type annotations according to actual return values and behavior
3.  Improved type clarity for polynomial representations, generators, and domain interactions
4. Ensuring complete compatibility with existing behavior, correct ruff format and passing all test cases and mypy checks

The aim is to enhance maintainability, static correctness, and developer experience without changing runtime functionality.

Any review or guidance will help me a lot

Thank you 

- vedant Dusane

[Vedant Dusane]

Hello everyone,

I have been adding type annotations to SymPy and would like to continue with the polys. I thought I would like to share the files where I would like to work on and see if this is a good thing to do.

The files I am currently planning to add type annotations to are:

- sympy/polys/polytools.py
- sympy/polys/compatibility.py
- sympy/polys/polyclasses.py
- sympy/polys/euclidtools.py
- sympy/polys/polyoptions.py
- sympy/polys/matrices/domainmatrix.py
- sympy/polys/matrices/sdm.py
- sympy/polys/ring_series.py
- sympy/polys/rootisolation.py
- sympy/polys/subresultants.py

Their are too many in all this file that are left to annotated. currently i am trying to cover the whole file  "domainmatrix.py" . so let me know is this sound's good . If yes then i will start drafting GSoC proposal in that way only .

Do these files seem like a good thing to work on, or would you suggest working on other files?

Best regards,
Vedant

[Vedant Dusane]

Hi all,

For the past few weeks, I have been busy working on the type annotations of the DomainMatrix layer. During my process, I found that many type annotations are not specific to the DomainMatrix class and are rather related to the inconsistencies between DomainMatrix and the low-level dup_/dmp_ polynomial helper functions and the higher-level interfaces.

The generic type parameter (Er) that was introduced in the DomainMatrix class does not always align well with the generic types in the low-level polynomial arithmetic helper functions. This has been causing many mypy conflicts and operator type conflicts. This has also been causing many casts to appear in the code, which should rather have explicit type information.

I was thinking of extending the current work to include:

1. Stabilizing and finalizing the current generic work on the DomainMatrix generic layer.

2. Synchronizing type variables between DomainMatrix and the low-level dup_/dmp_ polynomial helper functions.

3. Reducing generic duplication and eliminating unsafe casts.

4. Improving return type consistency in selected high-level polynomial interfaces.

The aim of the extension would not include annotating the entire polys subsystem but rather make the DomainMatrix-based polynomial matrix pipeline generically consistent.

Before expanding further in this direction, I would appreciate feedback on whether this scope sounds useful and aligned with SymPy’s current priorities

Thanks,

Vedant

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sympy/9b35522f-0329-468a-82f4-f32ccc37aa57n%40googlegroups.com.

[Vedant Dusane]

Issue link :- #29181

[Vedant Dusane]

It's PR link not issue sorry for the mistake 

PR :- https://github.com/sympy/sympy/pull/29181