On 4 November 2010 13:15, Stefan Behnel <[email protected]> wrote:
> Vitja Makarov, 04.11.2010 12:50:
>> 2010/11/4 Stefan Behnel<[email protected]>:
>>> Vitja Makarov, 04.11.2010 12:37:
>>>> I can call prepare and then update dict?
>>>
>>> Sorry, what?
>>>
>>> Please provide some more context in your mails, and *please*, stop
>>> top-posting.
>>>
>>
>> Ok, sorry.
>> That's all about __prepare__ where should it be called and how to join
>> dict with ns?
>>
>> I see one solution (in Pyx_CreateClass) :
>> 1. call __preapre__
>> 2. update returned namespace with values from dict
>> 3. call metaclass with this namespace instead of dict
>
> Ah, ok. A took a deeper look at the way __build_class__ works, then frowned
> a couple of times and moved over to reading the PEP, which explains stuff
> that __build_class__ doesn't even seem to do.
>
> http://www.python.org/dev/peps/pep-3115/
>
> Apparently, __prepare__ is meant to be executed *before* even evaluating
> the class body:
>
> """
> __prepare__ returns a dictionary-like object which is used to store
> the class member definitions during evaluation of the class body.
> In other words, the class body is evaluated as a function block
> (just like it is now), except that the local variables dictionary
> is replaced by the dictionary returned from __prepare__. This
> dictionary object can be a regular dictionary or a custom mapping
> type.
> """
>
> So it's basically what gives you the dict that you assign the class members
> to (as you did in your original patch).
>
> I do not see why we should currently implement this, given that
> __build_class__ doesn't seem to follow that protocol either. It would just
> slow down the evaluation of the class body as we could no longer rely on
> the class dict being a dict.
>
> I think we can just ignore that part of the protocol for now - I doubt that
> many people will use it (or even know about it). Maybe worth a feature
> request on the bug tracker, but not more.
As the PEP mentions, __prepare__ is especially useful for establishing
in what order members are defined. To quote:
" In particular, there is an important body of use cases where it
would be useful to preserve the order in which a class members are
declared. Ordinary Python objects store their members in a
dictionary, in which ordering is unimportant, and members are
accessed strictly by name. However, Python is often used to
interface with external systems in which the members are organized
according to an implicit ordering. Examples include declaration of C
structs; COM objects; Automatic translation of Python classes into
IDL or database schemas, such as used in an ORM; and so on. "
If it's a hassle to implement then users could always just write this
stuff in pure python though (as they have to do currently).
> Stefan
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev
>
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
