> 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