On Wed, Sep 17, 2008 at 4:54 PM, Dag Sverre Seljebotn <[EMAIL PROTECTED]> wrote: > Lisandro wrote: >> I've almost finished the transform in charge of embeding functions >> signatures in docstrings. I want to ask your about some issues I need >> to handle to finish it. >> >> * Position in the transform pipeline: I'm curently inserting the >> auto-signature transform after the 'ResolveOptions' one in the >> transform pipeline. Dag, tell me if this is OK. > > For this, anywhere where you have the needed information available is ok. > I guess you read the type info from nodes then, and not the "parsed" info > that is available later? (that could make sense and is not necesarrily a > bad sign) >
I did not understand you here, but anyway it seems to work at the place I'm inserting it. Or perhaps I could get more info (like return type in 'cpdef' funcions) if I insert the transform near the end? >> * Remove identation?: What do you thing about previously call >> 'textwrap.dedent()' on the original function docstring if it is >> present? Do you believe there ar use cases for preserving the common >> level of identation in docstrings? If docstrings are not 'dedented' >> (Do such word exists?), then we are going to be carefull about the >> other option '--embed-positions', that do not take into account >> docstring identation. > > -1. An aim is as high degree of Python compatability as possible, and > dedenting automatically would mean less Python compatability (without any > really good reason). > > Taking the inverse approach seems better: Scan for common indentation and > insert that prior to the signature you are inserting. > > Remember that some issues/features (like any issues with indendation) can > just be left for later though; "release early, release often!". > Well, then this will be for the future, I'm not sure what to do in every case (docstrings could start with 0 or more blanks and next a newline, or docstrings could start with some text provining a short summary, like in numpy, and all that variants!): > Perhaps attach patches to the ticket and ping the list when the issues > above is sorted out? OK, > If you don't like working on a hg clone, have you looked at the hg "queue" > functionality for creating, pushing and popping patches? Then you don't > need a script. (Just a tip.) Yes, I know about hg queues, bet never got learn really understand them. I'll just clone and post patches. > Open question: Do you plan to submit a patch to epydoc (would they even > consider Cython support?), or is it something that should be shipped with > Cython somehow? Perhaps in the near future we can ask the Epydoc developer so suport Cython. But we should ship a tool with Cython for the moment. Epydoc is prepared for building signatures for core Python builtin functions and methods, and the 'format' of those signatures are quite different to what I'm currently generating. If we want to use Epydoc right now (and in the future, with current 3.0.X version) we will need my monkeypatching script. It is a real short script, take a look: http://petsc.cs.iit.edu/petsc4py/petsc4py-dev/file/dba78e8da92a/misc/epydoc-cython.py -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
