Jason Tackaberry wrote: > On Mon, 2009-05-04 at 08:38 +0100, Adam Charrett wrote: >> Thanks Jason, I don't believe that form was available when I wrote the >> original code. > > That's probably true. It was only recently added (back in February). > >> I did find it difficult to find a nice way of documenting >> the signals and this certainly seems like a very nice inline way of >> doing it. I ended up adding them to the class documentation, but without >> any markup :-( > > Yeah, although to benefit from the signal docstrings you really need to > be using reST, in combination with the doc generation stuff provided by > kaa.base, which extends Sphinx in useful ways.
I'm still in two minds about the benefits of Python 2.6 documentation tools. Hopefully you'll correct me but I like printed documentation over electronic documentation. Mainly because we read electronic documentation differently than paper documentation, we tend to skim electronic documentation. What's the first thing we do when we come to something new? Try to find an example of how it should be used and then read the reference documentation. Finding an example is where electronic documentation wins out over paper but paper wins when it comes to reading the details. One example of where the 2.6 documentation fails quite badly over the previous version is the Windows CHM file. I don't yet see where epydoc is any different that reST; epydoc is just an another form of reST. Duncan ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
