Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: > One thing: I think it would be good if the output is something very > targeted (i.e. not simply new SimpleCallNodes or similar). From the > refnanny it seemed that very many CPython API calls used the same > pattern, so perhaps something along the lines of a PythonApiCall-node, > perhaps with a NoneCheckNode as its "subject", and so on.
Fine with me. I also thought about a "NoneCheckNode" when I wrote this. That would be a very simple and explicit thing, and also very easy to handle (or optimise away) in later transformations and during code generation. A PythonApiCall node might be a good idea (needs some more thinking) and would relieve us from having to generate all sorts of Entry's & friends. > Some of the resulting operations could warrant their own node Yes, I gave an example with the int vs. None return value. There's also the issue that many methods of builtins have their own specific exceptions when passing None values. This needs to be handled, and a PythonApiCall node would be a good place to do it. >> This might(!) depend on (or at least benefit from) splitting up the type >> analysis phase (as discussed before, looks like we still need a ticket for >> this), so that we can recognise the declared/builtin names when running >> the transform, and can handle the final return values appropriately (which >> are sometimes boolean ints instead of (None) Python objects, for example) >> *after* switching to the corresponding C-API function. > > This is a going to cause at least as much trouble as the new temps > (though that is going to be worth it in the end, and so could this). At > least myself I am not decided on how I'd like to see such a split -- I > know I advocated it a year ago, but now "first names, then expressions" > seems a bit suboptimal to me. "First declare possible types, then > transform, then resolve and insert coercion nodes and raise any errors" > seems promising but I'm still unsure about it. Yes, this needs some discussion. For 0.12, we may just try the optimisation and see how far it takes us without this split. That will also make it clearer if, why and how this needs to be done. > If there's a chance of a Cython workshop during the coming year I'd say > these kind of matters (and the actual coding) can be resolved more > easily that way. Otherwise it seems to stand between one person with a > bright idea doing it all alone, or one of those 100-emails-threads > converging very slowly towards the right solution... ;) Certainly not a task for a GSoC student. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
