On Sat, Oct 31, 2009 at 10:03 PM, Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > On Sat, 31 Oct 2009 16:53:50 -0500, Peng Yu wrote: > >> I know that multiple classes or functions are typically defined in one >> file (i.e. module in python). However, I feel this make the code not >> easy to read. Therefore, I insist on one class or function per file (i.e >> module in python). >> >> When one class per module is strictly enforced, there will be no need to >> have different capitalization conventions for modules and classes. >> Developers should be able to tell whether it is a class or a module from >> the context. > > Classes and modules are first-class objects in Python, so you can't > necessarily tell what they are from context. I frequently have code like > this: > > > def verify(test_func, objects_to_process, expected_results): > for obj, result in zip(objects_to_process, expected_results): > print "Testing %r..." % obj, > r = test_func(obj) > if r == result: > print "verified" > else: > print "expected %r but got %s" % (result, r)
This example doesn't invalidate my statement. When I say "Developers should be able to tell whether it is a class or a module from the context", I mean the case of defining them or creating objects. In the above case, you still can enforce one class/function per module. > objects_to_process could be a list of floats, strings, functions, > modules, or anything else. Having a naming convention is still useful for > distinguishing (say) factory functions from classes, or modules from > classes. > > >> In my question, module A and B exist just for the sake of >> implementation. Even if I have module A and B, I don't want the user >> feel the existence of module A and B. I want them feel exact like class >> A and B are defined in module 'test' instead of feeling two modules A >> and B are in package 'test'. > > > Inside test/__init__.py: > > from A import A # class A from file A.py > from B import B # class B from file B.py I can not use the above approach as I mentioned its problem in my previous message. > or better still: > > from a import A # class A from file a.py > from b import B # class B from file b.py This artificially introduces the constraint that the file name can not be the same as the class/function name. There is no constraint like this if I can C++. >> I know that module names should be in lower >> cases, in general. However, it is OK to have the module name capitalized >> in this case since the end users don't see them. > > Of course they do. This sentence is confusing. Can you spell out what you mean? >> I looked at python library, there are quite a few __init__.py files are >> not empty. In fact, they are quite long. I agree with you that >> '__init__.py' should not be long. But I'm wondering why in python >> library __init__.py are quite long. > > Define "quite long". > > In Python 2.6, I have: > > [st...@sylar python2.6]$ for file in */__init__.py; do echo "$file" `cat > $file | wc -l` ; done > bsddb/__init__.py 450 > compiler/__init__.py 29 > ctypes/__init__.py 546 > curses/__init__.py 59 > distutils/__init__.py 26 > email/__init__.py 123 > encodings/__init__.py 157 > hotshot/__init__.py 78 > idlelib/__init__.py 1 > json/__init__.py 318 > lib2to3/__init__.py 1 > logging/__init__.py 1490 > multiprocessing/__init__.py 271 > sqlite3/__init__.py 24 > test/__init__.py 1 > wsgiref/__init__.py 23 > xml/__init__.py 47 > > > > With the exception of logging, I don't see any of those as quite long. I have defined 'long' in one of my previous message. I consider a file long, when it does not fit in one or two screen. Basically, I want to get a whole picture of the file after glancing of the file. -- http://mail.python.org/mailman/listinfo/python-list