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. > 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. - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
