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. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
