On Mar 15, 2009, at 7:17 PM, C. Titus Brown wrote: > - PEP 8? All code that I changed during the metabase refactoring, I re- formatted to PEP8 style. I did not go through all the unchanged code and reformat as PEP8, because I wanted as much as possible for reviewers to be able to see exactly what my changes were, using git- diff. Now that all the substantive changes are done (unless your code review determines otherwise), we can PEP8 the whole thing.
> > - a doctest-style introduction to the new functionality would be very, > very helpful. Pardon my ignorance, but I'm unclear what level of detail doctests should be written for. Perhaps you can give me some advice on several things that confuse me: - Only a few classes in this module are intended for public use by ordinary users, and therefore seem appropriate for writing doctests. - I want to strike a balance between code clarity and the fraction of space taken up by comments. Can you suggest what principle for doctests will give this right balance? Show one typical usage example of each public class? - if that is the goal, I have already provided such examples in the test modules. I wrote all these in the test modules, and not as doctests, because you said you had turned off doctests. If you want to move these tests to doctests, then we need a clear statement about which tests belong in doctests vs. in the test modules, and we need to activate the doctests as part of the automated test suite. - For doctests of internal classes / methods, often many preliminary setup steps are required before you can use such an internal class or method. Such setup code is meaningless boilerplate (little or no documentation value), is solely for testing purposes, and seems to have no place in the core module code. Isn't that what we have separate test modules for? > > - the test framework does not properly handle code coverage analysis > for this code (because figleaf is not enabled prior to import of > pygr.Data -- I'm fixing), but I get the impression that test > coverage > is not terribly thorough. Are you sure about this? I'd expect the coverage to be higher than other modules such as seqdb, because there is no old, unused code in metabase. The main holes in testing I can think of are: - schema deletion - some deprecated, legacy methods, e.g. addResourceDict - some minor descriptors not currently used by metabase itself, e.g. ItemDescriptorRW. > > > I can probably hack and slash my way through the file with my usual > blunt machete, but anything you can do to introduce me to the code > would > help! It sounds like what you want is usage example code, not text documentation. Or do you want a roadmap showing how the basic components work with each other? -- Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
