Order in metaclass

[Thomas Heller]

Carlos Ribeiro <carribeiro at gmail.com> writes:

> On Wed, 13 Oct 2004 21:32:20 +0200, Thomas Heller <theller at python.net> wrote:
>> And for your original question: why do you insist on your new syntax,
>> why don't you simply (as ctypes also does it) define the attributes in a
>> list, when they have to have a certain order?
>
> I can't speak for Nicolas, but I can for myself. There are three
> reasons, in my particular case:
>
> -- The order is already there, explicit in the way the code is
> written. I see no reason to be forced to state it _again_, specially
> considering the fact that this is prone to errors; for example,
> missing elements, duplicated elements, or out-of-order elements (in
> ordered differently in the code and in the list).

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 make extensive use of nested structs. In this case it's _much_
> easier to make mistakes as the ones mentioned above.
>
> -- Using classes and inheritance, it's easy to add new members or
> redefine existing ones. But I would need to re-state the full list for
> any descendant. To make matters worse, in this case, whenever I make a
> change to the base class, I would have to change _all_ descendant
> classes. Not exactly good OO design. Of course, clever hacks could
> possibly be used, but then, it wouldn't look any better than Nicolas
> (or my own) ordered-attributes hack.

In ctyoes you write:

class POINT(Structure):
    _fields_ = [("x", c_int),
                ("y", c_int)]

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)]

> 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.

Thomas