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
REF: Refactor to avoid circular dependencies #2831
Moving off-topic part of discussion in #1628.
The learning curve for newbies (this guy!) would be easier if the dependency structure between modules were simplified. Some low-hanging fruit I would like to refactor:
Seems reasonable. Although all the "search directory for whatever" functionality might merit its own module at some point. It's fairly complex (and probably needs to be, at least a little). It's a good start, though.
No, but I think it should work to move the
There are probably some uncomfortable details somewhere that escape me right now, but this sounds like a good idea. There are basically four types of options: the debug flags and the global ones in
Overall, I don't really see enough to put into a "utility" sub-package. I rather see a functional split between "scanner/parser", "syntax tree nodes", and "transformations". Potentially also the "type system" (PyrexTypes + Buffer + MemoryView + maybe Builtin), which is really what makes Cython a programming language. But I don't think it's a good idea to split up the package right now, when we might end up with a long-living Py2 legacy branch where any difficulty to cherry-pick changes will the a major annoyance. That's a decision to postpone until we have decided when and in which version to cut off the Py2 support. If we do it after the next release, then doing any restructuring before that would actually be helpful. Although, flat is better than nested, right? ;)
Totally reasonable. Unless there is a better shorthand available, I'm going to keep referring to these modules collectively as
Can't argue with the principle.
I'll put together a PR with the parts of this that you're on board with. Later I might make a proof of concept for other parts, in particular the