Hi everyone, I am currently contributing type annotation improvements around DomainMatrix. Would extending this work to align typing in the polynomial helper functions be a reasonable direction for GSoC proposal??
Thank you -vedant dusane On Tuesday, 3 March 2026 at 11:14:11 UTC-8 Vedant Dusane wrote: > 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/e1b46cee-7c24-456b-8bc0-8b713f79e024n%40googlegroups.com.
