On 10/24/2012 03:15 PM, Nick Coghlan wrote:
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.
Either the code is a "tangled monolithic mess" or it isn't. If it is,
then let's fix that, regardless of the size of the file. If it isn't, I
don't see breaking up the code among multiple files as providing any
benefit. And I see no need for the toolchain's assistance to help us do
something without benefit. The line count of the file is essentially
unrelated to its inherent quality / maintainability.
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.
I'm all for good software engineering practice. But can you cite
objective reasons why large source files are provably bad? Not "tangled
monolithic messes", not poorly-factored code. I agree that those are
bad--but so far nobody has proposed that either of those is true about
unicodeobject.c (unless you are implicitly doing so above), nor have
they proposed credible remedies. All I've seen is that unicodeobject.c
is a large file, and some people want to break it up into smaller
files. I have yet to see anything but handwaving as justification. For
example, what is this barrier to entry you suggest exists to hacking on
the str object, that will apparently be dispelled simply by splitting
one file into multiple files?
Someone proposed breaking up unicodeobject.c into three distinct
subsystems and putting those in separate files. I still don't agree.
It seems natural to me to have everything associated with the str object
in one file, just as we do with every other object I can think of. If
this were a genuinely good idea, we should consider doing it with every
similar object. But nobody is proposing that. My guess is because the
other files in CPython are "small enough". At which point we're right
back to the primary motivation simply being the line count of
unicodeobject.c, as a purely aesthetic and subjective judgment.
//arry/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com