It's PR link not issue sorry for the mistake PR :- https://github.com/sympy/sympy/pull/29181
On Wed, 4 Mar 2026, 00:24 Vedant Dusane, <[email protected]> wrote: > Issue link :- #29181 > > On Wed, 4 Mar 2026, 00:23 Vedant Dusane, <[email protected]> wrote: > >> 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/CAHWzp3QX-BmgSzE%2BkN6_GatWYLJNf7c-7HTnTCD6rwA%3DhXqtiA%40mail.gmail.com.
