Lisandro Dalcin, 29.08.2010 18:13:
> On 29 August 2010 04:36, Stefan Behnel wrote:
>> Lisandro Dalcin, 29.08.2010 03:39:
>>
>>> On the other hand, I do not care too much if this is implemented going
>>> through a descriptor, but as I'm not going to use this feature anyway.
>>
>> I think that describes the main use case already: "I won't use it in my
>> code, but the users of my code *may* want to have it". That's the main
>> reason why I'm advocating a low impact for the unused case.
>
> If users want a dict in their instances, then use a subclass. That the
> way to have to do it for built-in types like list or dict.

That works if it's the user who instantiates the type. It won't work for 
module internal types that are only instantiated by a library. That's not 
uncommon. Also imagine the case of a number-like type that implements all 
sorts of numeric methods. If you want to use a subtype that provides a 
__dict__, you may have to override all sorts of (special) methods to make 
sure it returns the new subtype instead of the extension type itself. 
That's a lot of overhead just for being able to store an attribute on an 
object.


>> Note that your patch only solves half of the problem that Neal describes:
>> it implements __dict__ for instances but not for types.
>
> Adding support for modifying type dict's is a completely different
> feature. It will require more careful implementation because of the
> type cache in Py>=2.6

Sure.


> and it would likely require some dedicated
> syntax of @cython decorator, because cdef __dict__ would apply to
> instances and not to the type.

Agreed for the "cdef __dict__" syntax. However, is there a reason why 
extension types can't provide modifiable __dict__ support by default? After 
all, subtypes can basically override all sorts of internals anyway, so 
there's not much of a difference if __dict__ is used to override them or if 
a subtype does that. Does anyone know of a reason why it could result in 
unexpected/unwanted behaviour if we make all extension type dicts modifiable?

If the problems are just related to types that are not supposed to be 
subtyped in the first place, the long-proposed "final" modifier would be a 
better solution (and it would simply make the type __dict__ read-only as 
before).

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

Reply via email to