Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Code base cleanups #2825
Collecting a few potential-cleanup targets as I find them, in case the answer is "go for it!"
Bigger-picture, coming at this from a direction of a newcomer interested in solving #1628, #1461, and implementing linting for cython files, it seems like there would need to be a stronger separation between the "parsing cython" part of the pipeline and the "turning it into C" part.
Thanks for volunteering. I agree that improving the linting coverage would be nice. Cython has a very old code base (since 2001), and we only recently added a simple initial linting configuration at all. But read on.
Cleaning up Plex seems good. It's been mostly unchanged since we inherited it from Pyrex (where it already was a copy of some old Plex version), and it's unlikely to receive many changes in the future. It does what it should, and it does it well. So, stripping down the code to what's actually used is reasonable. But again, read on.
I doubt that using
I'm not sure what you mean by "a stronger separation" between parsing and code generation. Both are independent steps in the compiler pipeline that are connected by a parse tree. The main issue in #1628 is that this parse tree was not meant as a user facing AST, so it a) lacks some abstraction and b) is not meant as a stable API. Committing to it as it stands would reduce our future flexibility to evolve Cython as a language, so I'm not very eager to open it up at this point.
If you're interested in the parser part, then look at
That's not an easy project, though. In order to make sure the grammar does not get stale again, we'd best use it ourselves as a parser in Cython, which means that we'd have to extract some smartness from the existing parser into later pipeline steps. That should be somewhat straight forward in most cases, but needs some work. And it also has a somewhat open outcome in that the result needs to convince us to give up the current convenience of just being able to do stuff in the existing parser. The main advantage would certainly be that such a parser could be reused and extended by external tools, such as a linter. Although I don't know of any linting tools that are directly based on Python's Grammar file… Anyway, #1628 is the right ticket for that.
#1461 seems unrelated. It's mostly about fixing the way Cython generates line tracing calls. Probably trivial to fix once we know when/where exactly to report the line execution.
I'll put together a PR.
six is nixed, got it.
Will do, probably a separate PR (I hope you're OK with the multiple-self-contained-PRs style)
The three are connected in as much as the complex dependency graph makes a serious barrier to entry for newcomers (at least this one). The "stronger separation" suggestion is speculation about refactoring that might make this easier; even if that were a high priority, mine is not a particularly expert opinion. I'll take this part of the conversation to #1628.