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.
