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/CAHWzp3RiXd1h_5tZ9MvZJZ%2BVEW3HbbA17eNLq5%3DLouycf6Cxtg%40mail.gmail.com.
