On Sat, Oct 31, 2009 at 9:34 PM, Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > On Sat, 31 Oct 2009 18:29:35 -0500, Peng Yu wrote: > >> If two functions are too long to put in file, I generally put them in >> two different files. > > If two functions are too long for a single file, the functions are too > big and need to be broken up into ten or thirty sub-functions each! > > Ideally, no function should be more than ten or twenty lines (plus > docstring), certainly no more than a page. In a language like Python that > is so compact, monster functions that are hundreds of lines long is > almost certainly inexcusable. > > >> And I always put a single class in a file. > > An unnecessary and silly restriction. It is reasonable for large > complicated classes, but not a rule for all classes, some of which might > be as small as two lines. > > >> Suppose that I have many functions in one file, it is not clear to see >> how many functions are in the file at first glance. > > So what? Why is it import to see how many functions are in the file? > > > >> If I put each function in its >> own file, just by looking at the directory structure, I can easily see >> how many functions there are. > > Why do you care how many functions there are?
Because I want to easily see what functions are there. >> One advantage is on refactoring. When each function has its own file, I >> can change variable names, etc., for a give function without worrying >> accidentally change variable names in other functions. > > Do you understand that each function has it's own local namespace? Unless > you are foolish enough to use global variables for everything, you can > refactor any given function without effecting other functions in the same > file. > > >> When I find a >> function is more appropriate to put in another namespace, I can just >> move the file around. > > A module is a namespace. This is a constrain imposed by python. C++ does not have this constraint, so I can have each class in a file without any complication in calling classes. Because of this constraint in python. I have do something from spam import spam or call spam.spam. >> Another advantage is on testing. I can have associated test dir for each >> class or function. By this way I can easily locate the definition and >> the test to track any potential problems. > > You can do this when functions share the same file. > > >> You can use package rather than module to group semantic related classes >> and functions. > > Python makes available many namespaces: > > Function > Module > Package > > You are artificially restricting yourself to use: > > Function = Module > Package > > and that's supposed to be an advantage??? Since Module = file, by making Function = Module and Class = Module, it simplifies the search of a function and a class. I also put the testing code along with the module, which make it easier to move module across packages (when I do refactoring, sometime I found some module is not appropriate to put in a package anymore, so I need to move it to a better package). -- http://mail.python.org/mailman/listinfo/python-list