>> I don't think the compiler can determine the order in
>> all cases. Consider:
>>
>> class Spam:
>>
>> if moon_is_full:
>> alpha = 1
>> beta = 2
>> else:
>> beta = 2
>> alpha = 1
>
> This is also expected to work in class namespaces:
>
> locals()["alpha"] = 1
On 24 March 2015 at 08:22, Greg Ewing wrote:
> Martin Teichmann wrote:
>>
>> maybe
>> we could just change the compiler to leave the order in which things are
>> defined
>> in a class in the class namespace, say as a member __order__? Then we
>> could
>> use plain-old dicts for the class namespace
Martin Teichmann wrote:
maybe
we could just change the compiler to leave the order in which things are defined
in a class in the class namespace, say as a member __order__? Then we could
use plain-old dicts for the class namespace, and we would not slow down class
creation (not that it matters mu
> For folks that haven't looked at the tracker issue: I personally like
> the change, but it does involve storing the cell object in a
> dunder-variable in the class namespace while it's being defined (until
> type.__new__ executes and both populates it and removes it from the
> class namespace).
On 21 March 2015 at 00:03, Martin Teichmann wrote:
> The current python fails the assertion, while with my patch everything is
> fine,
> and I personally think __class__ should always actually refer to the class
> being
> defined, which means at the minimum that it is actually, well, a class.
F
Hi list,
while a class is being initialized in a metaclass, it is not always possible to
call classmethods of the class, as they might use super(), which in turn uses
__class__, which is not initialized yet.
I know that this is a known issue, but well, sometimes it even makes sense
to fix already
