On Tue, Apr 9, 2013 at 5:26 PM, Nils Bruin <nbr...@sfu.ca> wrote: > On Apr 9, 4:11 pm, Robert Bradshaw <rober...@math.washington.edu> > wrote: >> To let x.foo() call different functions depending on whether your in >> Cython or Python, or even worse whether x is fully typed, would be >> even more surprising. > > Does cython overload on type signature? I don't have a particular > problem with the semantics of cpdef, it's quite reasonable to have > something like that (python semantics, but an optimized common path). > I was just expecting it to be fully equivalent with > > cdef _private_cdef_method(...): > ... > def method(...): > return _private_cdef_method(...) > > with some magic to directly use _private_cdef_method wherever that > definition is available.
One can still write this if these are the desired semantics. > Incidentally, cpdef methods already have a way to bypass the attribute > lookup dispatch: they grow an extra parameter skip_dispatch. The > python wrapper actually calls it that way, because by the time that > gets called, all attribute lookup has already been done appropriately. > So if we could actually call > > cpdeffed_method(...,skip_dispatch=1) > > (which would then have to be translated to the appropriate C-code), we > would already have (something very close to) the fast path. I'm sure > there are better notations for this. > > Another (slightly less flexible) possibility would be a decorator > > @cython.no_dispatch > cpdef .... > > which would leave out the dispatch part of a cpdef method. > > Of course, we should probably first come up with a practical example > where this makes a measurable difference. However, given the trivial > access routines that some sage code has, I'd expect we could find such > an example. Making access to that attribute the critical part of a > loop might be a bit of a stretch though. > >> I bet we could leverage tp_version_tag though, I'm going to give that a try. > > Nope. That just tracks modifications of tp_dict, the MRO, and > modifications to tp_dict higher up in the MRO. I'm assuming that the > lookup in the vtab is already taking care of modifications there. It's all defined at compile time, and we leverage that the baseclasses are all Cython classes so you can't manipulate the dict directly. If we could tell that both tp_version_tag and the objects __dict__ didn't change, that should be sufficient (modulo perhaps issues with __getattr__ and the likes). > It seems to me that if a subtype decides to shadow a cpdef using an entry > in its tp_dict, while not touching the vtab and keeping > tp_dictoffset=0, the current dispatch code would not pick it up > anyway. Or would that be illegal according to python protocols? True. This could actually be dangerous (e.g. one could use __slots__ to avoid the creation of a dict). I think that's a bug. - Robert -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
