Opinions please -- how big should a single module grow?

Tomasz Rola rtomek at ceti.com.pl
Fri Jul 9 08:41:06 EDT 2010


On Fri, 9 Jul 2010, Steven D'Aprano wrote:

> This is a style question rather than a programming question.
> 
> How large (how many KB, lines, classes, whatever unit of code you like to 
> measure in) should a module grow before I should break it up into a 
> package? I see that, for example, decimal.py is > 3000 lines of code, so 
> I can assume that 3 KLOC is acceptable. Presumably 3000 KLOC is not. 
> Where do you draw the line?
> 
> For the purposes of the discussion, you should consider that the code in 
> the module really does belong together, and that splitting it into sub-
> modules would mean arbitrarily separating code into separate files.

Myself, I would draw "the line" somewhere between 20-50 KLOC&C (code with 
comments) - if something takes a lot of place to comment, then maybe it 
should go to a separate unit.

As of the other side of scale, this 3000 KLOC thing, I believe you would 
have encountered a performance hit. And probably a big one - I would be 
afraid of some O(n^2) dragon or something bigger, waiting deeply in 
CPython code to eat your performance. But, I am just fantasizing - I have 
no idea of CPython internals and how big is the biggest Python code 
written so far. Python code tends to be very concise, so 3 MLOC sounds 
rather extremal to me. On the other hand, it is possible nobody tested 
CPython for such extreme case.

Speaking of performance, there is also target user, and her needs (CGI? 
desktop? etc). So I would take this under consideration, too - how many 
times per second (minute, day) this code will be executed?

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola at bigfoot.com             **



More information about the Python-list mailing list