On Sun, Apr 8, 2012 at 9:28 PM, Peter Bittner <[email protected]> wrote: > Hi everyone, > > 2012/4/8 lkcl luke <[email protected]>: >> yep i think it's definitely time to do another pyjamas release. i >> tend not to push these too much because it's actually a heck of a lot >> of verification work. but, we have 650 people on the mailing list, so >> that should cover pretty much all the bases, between us. > > I'd like us to work on all the examples and clean them up first before > we head for a new release.
sure. > 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. > 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. l.
