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/CAHWzp3Ty_ANOt2ua%3DQDH%3D3cY0Wyeg1z4j_N%3D5Eh-geDAM%2B76Qw%40mail.gmail.com.
