[Cython] Bindings performance issue

[Robert Bradshaw]

On Thu, Jun 2, 2011 at 2:21 PM, mark florisson
<markflorisson88 at gmail.com> wrote:
> On 2 June 2011 23:13, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>> On Thu, Jun 2, 2011 at 2:03 PM, mark florisson
>> <markflorisson88 at 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