Lisandro Dalcin, 29.08.2010 19:36:
> On 29 August 2010 14:06, Stefan Behnel wrote:
>> Agreed for the "cdef __dict__" syntax. However, is there a reason why
>> extension types can't provide modifiable __dict__ support by default?
>
> I do not care if you what type dict's modifiable by default, as long
> as you grant me a compiler directive to switch the feature off.
I agree that a decorator makes sense here. I'm just considering whether the
feature should be on or off by default. In general, I think Python class
compatibility should win, so making type dicts modifiable by default would
be the right thing to do. Then we could add a @read_only_type_dict class
decorator that would enable the current (standard CPython) behaviour and a
@no_type_dict decorator that would disable it completely. Although I'd
prefer a single decorator, given that they are mutually exclusive. So maybe
@type_dict("readonly") and @type_dict("none") would be better, with a
default of @type_dict("public") and a potential extension to
@type_dict("private"), in case that can be made to work in a meaningful
way. Note that "none" must actually create a decriptor that raises an
exception on access. Simply setting tp_dict to NULL will not let CPython
handle the access automatically, thus resulting in a "readonly" type dict.
>> 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?
>
> Perhaps the ext type could break if users are able to change things in
> __dict__. Suppose you have two methods, both updating some internal
> cache or other internals... then if you let users to change one of
> these methods, the other could behave bad.
Sure, but the question is: can this break in a way that it couldn't if a
subtype did the same thing?
>> 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).
>
> It could work, too. But IMHO, a directive would be better: no need for
> special syntax and it can be globally set.
I think it's much better to use a decorator as that moves the declaration
immediately before the type definition, thus making it clearly visible how
the type will behave by looking up its definition.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
