2012/4/9 lkcl luke <[email protected]>: >> Also, we should regenerate the API documentation and update the >> comments in the code accordingly (if needed)---before any testing. >> (Where is the epydoc script that generates/generated the current API >> documentation?) > > err.... errr.... > > lkcl@teenymac:~/pyjamas/doc$ apt-cache search epydoc > epydoc-doc - tool for documenting Python modules (documentation) > python-epydoc - tool for documenting Python modules > python-pydoctor - Python API document generator > yhsm-docs - python-pyhsm documentation > lkcl@teenymac:~/pyjamas/doc$ > > apt-get install python-epydoc.
I believe you wrote something (half a year ago) about a customized epydoc that was used for generation...? Good. So, the ./doc/gendocs.py script generates it all? Fine. >> Personally, I'd like to do away with the pyjamas.log module in a new >> release. > > awwww :) yeah ok. > >> I have added pseudo-deprecation comments to the module's >> write() and writebr() methods already -- I think I mentioned that. For >> a 0.9 release I'd like to make the module throw an error when it's >> used, giving a hint on how to move current code. (It's not _that_ of >> an effort, really!) > > good god. actually helping people with legacy conversions. amazing. > > remember it has to break (fail) at compile-time. ok, more to the > point, it has to *always* fail. so throw a popup / fail on import. > so if someone even does "import pyjamas.log" it should go "barffff" > > the last thing you want is someone to deploy a live application, > never test the "error" path, and have a user throw up a "barfff" fail > message. I've added a "raise DeprecationWarning(...)" on top of the log module giving appropriate instructions for a) moving to the new pyjamas.logging module b) alternatively, continue using the pyjamas.log module for now This is not what I would consider a smooth transition, but heck, I have no better idea at the moment! :-) Peter
