> Michele Simionato already pointed you to `PEP 359`_. One of the reasons
> that I withdrew it was that people seemed to feel that you could get
> most of what you want now by defining appropriate metaclasses. In your
> case, for example, the appropriate metaclass and its usage might look
> like::
>
> >>> def instance(name, bases, dict):
> ... cls = dict.pop('__class__')
> ... dict.pop('__metaclass__')
> ... dict.pop('__module__') # silently added by class statement
> ... return cls(**dict)
> ...
> >>> class C(object):
> ... def __init__(self, a, b):
> ... self.a = a
> ... self.b = b
> ...
> >>> class c:
> ... __metaclass__ = instance
> ... __class__ = C
> ... a = 'foo'
> ... b = 'bar'
> ...
> >>> c.a, c.b
> ('foo', 'bar')
>
> Sure, it's misleading to use a class statement when you're not actually
> creating a class, but I guess people felt that wanting to do this was
> uncommon enough that they weren't worried about it.
>
i know that there is always a solution. But this problem show that
python and others are not coherent in the syntax (contrary to lisp for
example).
with the 'make' syntax, it will be really easy to translate a program or
a data structure defined in XML format into python syntax.
i do not know how many use-cases we need for changing a PEP status :)
another advantage is that we have the same syntax in all definition
levels: metaclass, class, instance.
and if we just want to use objects and do a sort of 'prototype
programming', we can with this syntax.
example:
instance my_obj(prototype_obj):
...
... object specialisation
...
sylvain
> .. _PEP 359: http://www.python.org/dev/peps/pep-0359/
>
> STeVe
--
http://mail.python.org/mailman/listinfo/python-list
