On Mar 9, 2009, at 5:17 AM, Stefan Behnel wrote: > Hi, > > there are a couple of tickets related to call optimisations. > > http://trac.cython.org/cython_trac/ticket/3 > http://trac.cython.org/cython_trac/ticket/131 > http://trac.cython.org/cython_trac/ticket/166 > > The getattr3() problem also relates to other cases, such as the > fact that > we can't currently optimise > > cdef list l = [...] > l.sort() > > into a call to PyList_Sort(), as this would break calls like > > l.sort(key=...) > > My suggestion is to remove the current support for optimised > methods of > builtins, and to write a dedicated transform that intercepts the > tree on > call nodes and that can then handle all cases in explicit code. > This can > include, for example, adding a None check if required, or handling > different call signatures only some of which can be optimised, > maybe even > by changing keyword arguments into positional arguments of a matching > C-API function.
This sounds like a good idea. Another option would be to support polymorphism (which would be good to do, at least for external C functions). > I imagine that it would use some kind of dispatch mechanism on > > (obj_type, obj_attribute_name) > > and on builtin function names. I also think that the current generic > "X.append()" optimisation (i.e. not only the one for typed lists) > should > go there. > > 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. > > Opinions? My one concern is that it would make type inference significantly more difficult by deferring this to a later phase (especially thinking in terms of methods that don't return PyObject*). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
