[Python-Dev] Split unicodeobject.c into subfiles (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Oct 25 00:15:14 CEST 2012

On Oct 25, 2012 2:06 AM, "Larry Hastings" <larry at hastings.org> wrote:

On 10/23/2012 09:29 AM, Georg Brandl wrote:

Especially since you're suggesting a huge number of new files, I question the argument of better navigability. FWIW I'm -1 on it too. I don't see what the big deal is with "large" source files. If you have difficulty finding your way around unicodeobject.c, that seems like more like a tooling issue to me, not a source code structural issue.

OK, I need to weigh in after seeing this kind of reply. Large source files are discouraged in general because they're a code smell that points strongly towards a lack of modularity within a complex piece of functionality.

Breaking such files up into separately compiled modules serves two purposes:

  1. It proves that the code isn't a tangled monolithic mess;
  2. It enlists the compilation toolchain's assistance in ensuring that remains the case in the future.

I find complaints about the ease of searching within the file to be misguided and irrelevant, as I can just as easily reply with "if searching across multiple files is hard for you, use better tools, like grep, or 'Find in Files'".

Note that I also consider the "pro" argument about better navigability inaccurate - the real gain is in modularity, making it clear to readers which parts can be understood and worked on separately from each other.

We are not special snow flakes - good software engineering practice is advisable for us as well, so a big +1 from me for breaking up the monstrosity that is unicodeobject.c and lowering the barrier to entry for hacking on the individual pieces. This should come with a large block comment in unicodeobject.c explaining how the pieces are put back together again.

However, -1 on the "faux modularity" idea of breaking up the files on disk, but still exposing them to the compiler and linker as a monolithic block, though. That would be completely missing the point of why large source files are bad.

Regards, Nick.

-- Sent from my phone, thus the relative brevity :)

/arry

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20121025/355c2b2c/attachment.html>

More information about the Python-Dev mailing list