On 2 June 2011 23:59, Robert Bradshaw <rober...@math.washington.edu> wrote: > 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..."
Ah, something like functools.partial. Yeah, that'd 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. >> >> 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.) Ok. Then perhaps it would be better to merge the support for fused types in the next release? I won't be available until the 6th of July for coding, so until then we'd be stuck with cython.fused_type() in a ctypedef. > - Robert > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
