While I understand what you're trying to do here (and think it would be quite nice), I'm not sure how you're going to accomplish it. How will parsing python using a syntax-tree help? It's not going to tell you what the function does in all cases or the various types it could handle. Perhaps you could make educated guesses by looking at the types of operations on the objects (a 'has_key' is a sure indicator of a hash), but that would be sketchy at best. For a ready example, imagine having a module that contains useful helper functions. How are you going to identify the type requirements of those functions if you don't have context? How can you be sure that you've convered all contexts (including conversions). Such is the nature of dynamic languages. It's very hard to do what you'd like to do here. -- Mike On Sat, Sep 07 @ 21:22, Hunter Peress wrote:
I think its easier to enforce this from the level i describe, than have guido saying "ok guys please be more explicit in your documentation". I mean, both of those documents above are somewhat explicit, but they are not COMPLETE.
Could you provide me with some linkage on parsing python (from a compilation/ syntax-tree analysis POV). SO that i can get to work on writing a patch for the pydoc generation program.
-- Michael Gilfix mgilfix@eecs.tufts.edu For my gpg public key: http://www.eecs.tufts.edu/~mgilfix/contact.html"