On 10 March 2010 15:46, Robert Bradshaw <[email protected]> wrote: > On Mar 9, 2010, at 11:12 AM, Lisandro Dalcin wrote: > >> We could get rid of structmember.h by using the transform+property >> machinery Dag implemented long ago >> >> So far, Robert has two concerns: >> >> 1) Dag's code had a few issues. >> >> 2) The generated code is less readable and bigger. >> >> Regarding (1), I'm working on it... the issues are minor, basically >> handle 'readonly' and auto-generate a docstring like "attribute 'ATTR' >> of 'TYPE' objects" (BTW, should this be on by default?). >> >> Regarding (2), I can certainly trade readability and code size, for >> many reasons: >> >> a) The header "structmember.h" is some sort of private stuff >> b) It is not even #include'd by default from Python.h, >> c) It is helpful for hand-written C code, but easy to get rid of in >> code generators like Cython. >> d) A big offence in that headers is that some definitions T_XXX are >> not properly namespace-protected with a Py_ prefix, then they can >> conflict with user code (as posted today in cython-users). >> d) Other issue is that C<->Python conversions are outside Cython's >> control of to_py/from_py converters, and this is IMO inconsistent. >> f) Finally, if readability and code size are so important in this >> case, we could latter provide a better implementation that does not >> rely on a tree transform. >> >> PS: Actually, I do not care too much about readability and code size >> in this case; Cython has already abandoned other readable, small-sized >> Python C-API idioms (e.g. argument parsing). > > Well, there are significant time savings in the argument parsing code. > > In any case, I agree the pros of getting rid of structmember.h > outweigh the cons, so +1 to doing it. >
OK.. BTW, Any suggestions about docstring generation? I mean: 1) Should the docstring be generated inconditionally, or under the control of 'embedsignatures' ? 2) The actual contents of the docstrig: currently it is: "attribute 'NAME' for 'CLASS' objects"... But it could also be "'TYPE' 'NAME'", where 'TYPE' is the C type of the member (so the rendering would be like the one for function arguments) -- Lisandro Dalcin --------------- 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
