Dear Prakhar, 1. That they are completely separate. So doing something for one does not benefit the other. Nor do they communicate with each other. However, they contain overlap in functionality. 2. I would expect such a project to have a complete restructuring of the classes involved. However, it is your project to propose. 3. It depends on what you want to do. For doing an initial PR, you can probably find an open easy issue to address on our issue tracker on GH.
The code given in this project should be backwards compatible (in particular, since it would likely be basically combining common functionality and internal workings). You can find information on writing Cython code on various online sources, including the main Cython page. Best, Travis On Monday, March 24, 2025 at 2:13:58 PM UTC+9 prakhark...@gmail.com wrote: > Dear Prof. Scrimshaw, > > I hope you’re doing well! I’m Prakhar Kapoor, and I’m excited about the > GSOC project to refactor FreeModule and CombinatorialFreeModule. I’ve > started looking into the code but wanted to clarify a few things as I draft > my proposal: > > 1. > > What are the biggest issues right now with having separate FreeModule > and CFM implementations? > 2. > > For the dense CFM, should we create a new class or tweak the existing > CFM? > 3. > > Are there specific parts of the codebase (or Sage tickets) I should > focus on first? > > Any tips on balancing backward compatibility or Cython best practices > would also be super helpful. > > Thank You. > -- You received this message because you are subscribed to the Google Groups "sage-gsoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-gsoc+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/sage-gsoc/0446b0dd-8485-407b-83d1-7d25ff02e3bdn%40googlegroups.com.
