Re: python project layout
> A concrete example would probably help. What are you envisioning? Let say you have an interface (zope.interface) IMyProduct and two classes implementing the interface MyProduct1 and MyProduct2 ... But I think I found the answer. One file each. Python is just more flexible than java in the sens that you dont NEED to do "one class" = "one file" -- h -- http://mail.python.org/mailman/listinfo/python-list
Re: python project layout
Huron wrote: > For instance, if you have several classes implementing the same > interface > (say, doing the same things with different strategies), how would you > organize that in terms of files (modules) and directories (packages) ? A concrete example would probably help. What are you envisioning? -- http://mail.python.org/mailman/listinfo/python-list
Re: python project layout
Huron wrote: > Hi Peter, > Thanks for you detailed reply. > The layout that you suggest sounds wise to me (I'm about to start a > project). I wouldn't necessarily recommend something so complex (not that it's particular complex, but it's more than just "flat") for a newcomer, however. One of the few small issues you have to deal with in order to get such a layout working properly is the "python path" issue, and how to import modules that are in another folder. Normally (aside from the standard library and extensions) only the current directory is in sys.path. Any subfolders that contain __init__.py modules are "packages" and you can import from them using the "dotted" notation (e.g. "import mypkg.mymodule" will try to load a file from ./mypkg/mymodule.py if there is also a ./mypkg/__init__.py (even if that file is empty!)). To import a module in the *parent* directory, however, is another story entirely. You need to get it added to the sys.path, and that's one of the things done (dynamically) by our test utilities, so we can be in the tests subfolder and type "story015.py" and have it load modules in the parent folder. So in short, start simple and let your layout evolve as you need it to. Don't try to start with a more complex layout than you need or know how to handle. And if you're using a revision control system like Subversion (and you better be using something! :-) ) then it's an easy matter to rename or move folders at a later time, without losing your revision history. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: python project layout
Hi again, For instance, if you have several classes implementing the same interface (say, doing the same things with different strategies), how would you organize that in terms of files (modules) and directories (packages) ? -- huron -- http://mail.python.org/mailman/listinfo/python-list
Re: python project layout
Hi Peter, Thanks for you detailed reply. The layout that you suggest sounds wise to me (I'm about to start a project). I confess that, coming from the java world, I've trouble to move away from the paradigm "one class" = "one file" ... and to gather things inside "python modules" ... -- huron -- http://mail.python.org/mailman/listinfo/python-list
Re: python project layout
Huron wrote: > What do you guys recommend in terms of python project layout, > especially > unit tests layout ? > Zope has unit tests per packages, twisted has a big tests directory > full of > tests ... and the file naming convention are also pretty differents ... > I guess there is part of "personnal choices" in those matters ... but > there > is also good practice advices that can be gathered I think ... (This is the result of a few years of evolution of our source tree conventions.) We place all tests in subfolders (named "tests") of the folders containing the files under test. Unit tests are named for the unit (module) they are testing, so serial.py would have a unit test file at tests/serial_unit.py. "Acceptance" tests (higher level usually black-box functional tests) are in the "tests" folder of the top level source folder, along with any unit tests that reside there, and take their name from the number of the requirement that defined them. Since we're an XP team, we call these requirements "stories", so the files are named exciting things like "story001.py" and "story197.py". The specific numbers match up with either index cards with descriptions of the requirements, or an online "issue tracker", depending on the project. We have a little (quite simple) internal utility that lets us easily run all unit tests under the current folder, or all acceptance tests in the project, with one command. (Specifically, "uix" and "stix" for unit and story tests, respectively.) This "test runner" utility scans subfolders (doing an os.walk basically) and executes each test script in a new process, to avoid most potential undesirable interactions between tests. The benefits are straightforward. Tests are easy to find for any file, but don't "clutter up" the same folder as the files under test. The naming conventions makes it easy to automate things like the test runner or other utilities. Running tests (always from a console) takes only a few seconds so we can do it often. Multiple projects are easily supported in other directory trees. -Peter -- http://mail.python.org/mailman/listinfo/python-list
python project layout
Hi, What do you guys recommend in terms of python project layout, especially unit tests layout ? Zope has unit tests per packages, twisted has a big tests directory full of tests ... and the file naming convention are also pretty differents ... I guess there is part of "personnal choices" in those matters ... but there is also good practice advices that can be gathered I think ... - h -- http://mail.python.org/mailman/listinfo/python-list
