Hi Aasim sir, As you preferred modules(Polys) I read code (Polys.polytool). I have push a small and easy PR because i touched this file for first time so i want to do more changes. After getting more familiar with this file then i will try to solve some complex type annotation.
PR link *https://github.com/sympy/sympy/pull/29063* On Thursday, 29 January 2026 at 21:12:13 UTC-8 Vedant Dusane wrote: > Hi, > Thanks for the explanation – it helped clarify a lot of things for me. > > What I understand from your mail is: > > 1. Type annotation in SymPy is more about enhancing correctness and type > inference than just suppressing type checker warnings. > > 2. Adding types requires a good mental model of what each function and > object is about, or else type annotations will be confusing. > > 3. The public API should be kept stable, but internal helper functions > with unclear usage can be cleaned up or refactored as part of the typing > process. > > 4. This is a natural area where internal cleanup and typing overlap, and > modules like polys are especially important and relevant to this > > Going forward, based on this, my plan is to: > > 1. Spend more time analyzing the internal workings of candidate modules > (notably polys) before making any proposals. > 2. Look through the existing discussions and issues related to typing in > SymPy to get a better understanding of the current state of affairs. > 3.Begin to shift my focus from making small typing PRs to finding specific > areas of the internal code that can be cleaned up and typed in a single > pass. > > Thanks again for taking the time to explain this – it’s very helpful input > for crafting a good proposal. > > Best regards, > Vedant > > On Fri, 30 Jan 2026, 08:48 Aasim, <[email protected]> wrote: > >> Yes, type annotating the codebase is pretty much a necessity now >> and for SymPy in particular it can be extremely helpful. It lets you >> catch wrong types leaking into the wrong places very close to the >> surface instead of discovering a bug several functions deep into the >> call stack. >> >> A major fraction of the time on my own project went into type annotating >> the sparse polynomial rings and polynomials implementation. What I >> learned >> from that is that to type annotate any module in SymPy, you really need a >> very clear mental picture of what signifies what and what does what. If >> that >> picture is missing, which is I guess understandable in the beginning, you >> will struggle with this kind of project. >> >> Ideally, the public API should remain unchanged since many public >> functions >> are likely used across a wide range of downstream projects. At the same >> time, >> the internal private functions that currently have ambiguous input or >> output types >> should be refactored to have clear and unambiguous signatures. When a >> contributor >> encounters such cases while adding type annotations, they should in >> parallel work >> on this cleanup as well. >> >> For example, in my earlier work I added an internal function called >> _truediv >> to the PolyElement class. This function handles true division for the >> PolyElement to PolyElement case, but its accepted input types and return >> types are currently too loose and should be tightened. >> >> So behind the scenes, this project can also act as a parallel cleanup >> effort >> for the codebase. Personally, I feel that the polys module should be >> prioritized >> for this process of type annotation and cleanup. It will directly support >> other >> efforts, such as FLINT backend integration. >> >> Also, what should be clear is, this project isn't exactly about making >> type checkers >> like pyright happy and give no errors. It's more about the inference >> pyright does >> on types while type checking a file. What we ideally want is, when a user >> writes >> some code using SymPy, pyright for instance should be able to infer the >> right types >> in the code instead of inferring weird return types that it normally does >> as of now in >> case of SymPy. >> >> I remember there is a recent issue on the repo from Oscar, that discusses >> the current scenarios with types in SymPy pretty well. I would suggest >> anyone >> interested, to most definitely check that out. >> >> A major part of proposing a project for GSoC is figuring out what exactly >> to do, >> the contributor is expected to build enough understanding themselves >> around >> the idea (by running through the code and understanding what can be done >> or >> improved). >> >> On Fri, 30 Jan 2026 at 06:15, Vedant Dusane <[email protected]> wrote: >> >>> Hi all, >>> I am a first-year B.Tech student and I’ve been contributing to SymPy for >>> about the past month, mostly on typing-related work (for example, adding or >>> refining type annotations in *sympy.utilities*). I have had a few *PRs >>> merged *in this area. >>> >>> While working on these, I have learned a lot about keeping *PRs small* >>> and *focused*, making *return types* actually *usefu*l for *type >>> checkers*, and staying *consistent* with existing tools like *mypy* and >>> *ruff.* >>> >>> I am now thinking about a possible GSoC 2026 *project focused on >>> improving type annotations more systematically in SymPy* — likely >>> starting with sympy.utilities, but not necessarily limited to that. >>> Before I start drafting a proposal, I wanted to ask: >>> 1. Does this seem like a reasonable direction for a GSoC-scale project? >>> >>> 2. Are there particular modules or areas where better typing would be >>> especially helpful? >>> >>> Any suggestion or feedback will help me a lot >>> Thanks! >>> >>> -- >>> 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/f08998ff-74d3-4722-83e9-0db69d4cca03n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/sympy/f08998ff-74d3-4722-83e9-0db69d4cca03n%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/CAO0%2BxCUzEF7xoL%3Du9enLo6%3DB8bxGuS8hB29VcNcHFJUw%3DSTKAA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/sympy/CAO0%2BxCUzEF7xoL%3Du9enLo6%3DB8bxGuS8hB29VcNcHFJUw%3DSTKAA%40mail.gmail.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/53d0095a-32a8-44b1-803b-794721b65e3cn%40googlegroups.com.
