Order in metaclass

[Carlos Ribeiro]

On Thu, 14 Oct 2004 11:55:54 +0200, Thomas Heller <theller at python.net> wrote:
> Yes, but a Python pogrammer wouldn't expect these two samples to give
> different results:
> 
> class A(...):
>     x = 1
>     y = 2
> 
> class A(...):
>     y = 2
>     x = 1

I sincerely dont agree with this argument. A *experienced* Python
programmer wouldn't assume that these two samples would give different
results, because he *knows* that ordering doesn't matter. But many
programmers would be surprised if they tried to iterated over the
fields and had them return out of the original definition ordering.
It's not natural; it's something that you have to explain _why_.
 
> which makes it explicit that _fields_ is a list, which *has* a certain
> order.  And for inheritance, it's easy and explicit as well:
> 
> class COLORED_POINT(POINT):
>     _fields_ = POINT._fields_ + [("color", RGB)]

I agree that it's clear, and this is not a strong argument that I
could use for my own case. My own approach has to handle similar
situations for nested classes, also.
 
> > It's specially important to point out that I consider the source code
> > ordering to be _explicit_, and not implicit, as some people may
> > possibly say. In fact, is there anything more explicit than that? Only
> > people used to Python dicts would say otherwise.
> 
> The point I'm trying to make is that too much magic most of the time
> catches you later again.  But that's only my own experience.

Agreed. But the lack of ordering (which is really a side effect of the
use of the dict mapping to store class attributes, and not a clear
design decision in itself) is also something that strikes newcomers as
a 'surprise factor'; in a sense, I think this makes the field even.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com