On Thu, Jun 2, 2011 at 2:45 PM, mark florisson <markflorisso...@gmail.com> wrote: > On 2 June 2011 23:34, Robert Bradshaw <rober...@math.washington.edu> wrote: >> On Thu, Jun 2, 2011 at 2:21 PM, mark florisson >> <markflorisso...@gmail.com> wrote: >>> On 2 June 2011 23:13, Robert Bradshaw <rober...@math.washington.edu> wrote: >>>> On Thu, Jun 2, 2011 at 2:03 PM, mark florisson >>>> <markflorisso...@gmail.com> wrote: >>>> >>>>>>>> If anyone is assigning a Cython function to an object and then using >>>>>>>> it they're counting on the current non-binding behavior, and it will >>>>>>>> break. The speed is probably a lesser issue, which is what benchmarks >>>>>>>> are for. >>>>>>> >>>>>>> If you're binding functions to classes without expecting it to ever >>>>>>> bind, you don't really have bitching rights when stuff breaks later >>>>>>> on. You should have been using staticmethod() to begin with. And we >>>>>>> never said that our functions would never bind :) >>>>>> >>>>>> No, you're assigning it to an object, counting on being able to call >>>>>> it later on. E.g. the following is legal (though contrived in this >>>>>> example): >>>>>> >>>>>> sage: class A: >>>>>> ....: pass >>>>>> ....: >>>>>> sage: a = A() >>>>>> sage: a.foo = max >>>>>> sage: a.foo([1,2,3]) >>>>>> 3 >>>>>> >>>>>> If instead of len, it was one of our functions, then it would be bad >>>>>> to suddenly change the semantics, because it could still run but >>>>>> produce bad answers (e.g. if we had implemented max, suddenly a would >>>>>> be included in the comparison). This is why I proposed raising an >>>>>> explicit error as an intermediate step. >>>>>> >>>>>> If we don't promise anything, the contract is whatever the code does. >>>>>> That's the problem with not having a specification (which would be >>>>>> really nice, but is a lot of work). >>>>> >>>>> Functions on objects never get bound, they only get bound if they are >>>>> on the class. So your code would still work with binding functions. >>>> >>>> True. It would still break "A.foo = max" though. I'm not saying we >>>> should support or encourage this, but lets break it hard before we >>>> break it subtly. >>> >>> Again, such code is highly fragile and frankly incorrect to begin >>> with, as it's based on the assumption that "Cython functions" never >>> get bound. >> >> I agree, but I bet there's code out there depending on it, in >> particular workarounds for our current broken semantics will >> themselves break. > > Workarounds wouldn't break, as they would wrap the non-binding > function in another object, and implement __get__ to return a new > object that, when called, would call the original function with 'self' > as the first argument.
Depends on the workaround. I'm thinking workarounds like "oh, self isn't getting passed, guess I'll have to pass it manually here..." >>> Getting functions (defined outside of class bodies) to bind >>> in classes is a feature, I sometimes found myself to want it. So >>> basically an error would be fine, but it would prevent normal usage as >>> we have it in Python. >> >> The error would just be for a transition period. > > The transition period would be for an entire release? Yes, though hopefully a much shorter release cycle than this last one. I just haven't had time to fix those remaining failing Sage tests, and we keep merging in more and more stuff (which is good, but we're well overdue for a release by now.) - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
