On Thu, Oct 25, 2012 at 8:37 AM, Barry Warsaw <ba...@python.org> wrote: > On Oct 25, 2012, at 08:15 AM, Nick Coghlan wrote: > >>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*. > > Modularity is good, and the file system structure of the project should > reflect that, but to be effective, it needs to be obvious. It's pretty > obvious what's generally in intobject.c. I've worked with code bases where > there's no rhyme nor reason as to what you'd find in a particular file, and > this really hurts. > > It hurts even with good tools. Remember that sometimes you don't even know > what you're looking for, so search tools may not be very useful. For example, > sometimes you want to understand how all the pieces fit together, what the > holistic view of the subsystem is, or where the "entry points" are. Search > tools are not very good at this, and if it's a subsystem you only interact > with occasionally, having a file system organization that makes things easier > to remember what you learned the last time you were there helps enormously.
And if we were talking in the abstract, I think these would be reasonable concerns to bring up. However, Victor's proposed division *is* logical (especially if he goes down the path of a separate subdirectory which will better support easy searching across all of the unicode object related files), and I conditioned my +1 with the requirement that a road map be provided in a leading block comment in unicodeobject.c. speed.python.org is also making progress, and once that is up and running (which will happen well before any Python 3.4 release) it will be possible to compare the numbers between 3.3 and trunk to help determine the validity of any concerns regarding optimisations that can be performed within a module but not across modules. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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