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 On Sun, 22 Feb 2026, 13:11 Vedant Dusane, <[email protected]> wrote: > 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 > > On Wednesday, 11 February 2026 at 10:48:19 UTC-8 Vedant Dusane wrote: > >> 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 i*mproving >> 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 >> > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/sympy/9b35522f-0329-468a-82f4-f32ccc37aa57n%40googlegroups.com > <https://groups.google.com/d/msgid/sympy/9b35522f-0329-468a-82f4-f32ccc37aa57n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sympy/CAHWzp3Q6hQ6a_b6b7wX%2B0J32rNZhvS%2BYThiM8EhRb6etnEUihw%40mail.gmail.com.
