a new object definition

Sylvain Ferriol sferriol at imag.fr
Mon Sep 4 06:28:41 EDT 2006


> 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



More information about the Python-list mailing list