On Wed, Aug 18, 2010 at 11:29 AM, Stefan Behnel <[email protected]> wrote:
> Robert Bradshaw, 18.08.2010 20:16:
>> In terms of impacting user code, the only case it impacts is if people
>> access __getattr__ by name. Is anyone doing that?
>
> Well, yes, look at the test case I added.

It was a test in response to this regression :).

> It's quite common to map
> __getitem__ or __getattr__ on the other method respectively to provide
> different interfaces for a class, e.g. to provide a __getitem__ fallback
> for names that do not work as a Python identifier.

I've never seen this, but could see that being justified.

> You can also use the
> unbound __getattr__ method to read a sequence of attributes.

Would using the getattr builtin be a more natural way of doing this?
Or is the point to skip the normal attribute lookup steps?

> Maybe not the
> most common but still a valid use case. To me, it's enough to know that
> this breaks code at all, so it's no longer just a simple optimisation but a
> change that breaks a standard Python feature that currently works.

Yes, it's a backwards incompatible step backwards for cdef classes,
but I think we have a little liberty for cdef class special
methods--they already violate the python conventions in several ways
(e.g. for arithmetic).

Lets release 0.13 without this lookup regression/performance fix
(depending on your point of view) and keep the discussion open for
what to do for 0.13.1 (which, if it isn't out soon, may require a
patched Cython for Sage.)

- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to