GSoC 2026: Exploring a project on improving type annotations in sympy

[Vedant Dusane]

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 useful 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!

[Aasim]

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).

--
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 sympy+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sympy/f08998ff-74d3-4722-83e9-0db69d4cca03n%40googlegroups.com.

[Vedant Dusane]

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

To view this discussion visit https://groups.google.com/d/msgid/sympy/CAO0%2BxCUzEF7xoL%3Du9enLo6%3DB8bxGuS8hB29VcNcHFJUw%3DSTKAA%40mail.gmail.com.

[Vedant Dusane]

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