PEP: Specialization Syntax

[Nicolas Fleury]

Hi everyone, I would to know what do you think of this PEP. Any comment
welcomed (even about English mistakes).

PEP: XXX
Title: Specialization Syntax
Version: $Revision: 1.10 $
Last-Modified: $Date: 2003/09/22 04:51:49 $
Author: Nicolas Fleury <nidoizo at gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 24-Jul-2005
Python-Version: 2.5
Post-History:
Abstract

This PEP proposes a syntax in Python to do what is called in
this document "specialization ". It contains more than one
proposal:
- Extend square brackets syntax to allow a full call syntax,
using a __specialize__ method, similarly to the __call__
method.
- Extend function definition syntax to allow specialization
of functions.
- Parameterized types.
Motivation

In his controversial blog entry "Adding Optional Typing to
Python -- Part II" [1], Guido Van Rossum introduced the idea
of "parameteri zed types" in Python. The proposition was to
use [square brackets] rather than <pointy ones> to allow
prototyping with __getitem__ method. However, the __getitem__
method is not flexible enough. It doesn't support keyword
arguments and using multiple and default arguments can be pain,
since the only argument received would be a tuple. Calling
can also be error-prone if a tuple can be allowed as a first
argument. This PEP proposes to enhance square brackets syntax
to allow full-call syntax as with parenthesis.

Note that Guido dropped the idea, for now, of parameterized
types in a following blog entry [2]. This PEP introduces
parameterized types only as a last step, and focus more on
having a syntax to prototype them. This PEP can also serve
as a place to discuss to feature of specialization independently.

The term "specialization " is used in that document because
"parameteri zed functions" would sound like an already available
feature. As Guido pointed out [1], "generic" is neither a good
term. Specialization is a term in that case borrowed from C++.
The term alone is not perfect, since it refers to the action of
passing arguments to a "parameteri zed type" (or function) to
make it usable and a term must still be found to describe the
"unspeciali zed" type or function.

Another motivation to this PEP is the frequent usage in Python
of functions to create functions. This pattern is often used
to create callback functions and decorators, to only name these.
However, the fact that both the creation and the use is using
parenthesis can be confusing. Also, a programmer ends up naming
two functions, when only the creating one is called by name and
the created one is doing the job. Some programmers ends up
naming the creating function with the name they would want to
give to the created function, confusing even more the code using
it. To fix this situation, this PEP proposes a syntax for
function specialization.
__specialize__ Special Member Function.

The first element of this proposal is the addition of the
__specialize__ special member function. The __specialize__
function can have the same signatures as __call__. When
defined, the definition of __getitem__ has no effect, and
__specialize__ will be called instead.

The language grammar is extended to allow keyword arguments
and no arguments. For example:

class MyObject(object ):
def __specialize__( self, a=4, b=6, *args, **kwargs):
pass

obj = MyObject()
obj[b=7, a=8, c=10]
obj[]

Note that when __specialize__ is defined, __setitem__,
__getslice__ and __setslice__ are still used as before.
The specializer Decorator

To explain the syntaxes proposed in this PEP, the following
decorator is used:

class Specializer:
def __init__(self, callableObj):
self.callableOb j
self.__name__ = callableObj.__n ame__
def __specialize__( self, *args, **kwargs):
self.callableOb j(*args, **kwargs)

def specializer(cal lableObj):
return Specializer(cal lableObj)

It takes a callable and make it callable with square brackets
instead.
Function Specialization

A common pattern in Python is to use a function to create
another function:

def makeGetMemberFu nc(memberName):
def getMember(objec t):
return getattr(object, memberName)
return getMember

foo(makeGetMemb erFunc('xyz'))

The second element of this proposal is to add a syntax so
that the previous example can be replaced by:

def getMember[memberName](object):
return getattr(object, memberName)

foo(getMember['xyz'])

which is equivalent to:

@specializer
def getMember(membe rName):
def getMember(objec t):
return getattr(object, memberName)
return getMember

foo(getMember['xyz'])
Class Specialization

The last element of this proposal is to add a syntax to pass
arguments to class creation:

class List[ElementType=obj ect](list):
...

This would be the equivalent to:

@specializer
def List(ElementTyp e=object):
class List(list):
...
return List

Note that the additional syntax is inserted before the
inheritance, different than what was initially proposed [1].
The reason is that inheritance can need the specialization
arguments, and it is more intuitive to use an argument
after its introduction:

class MyList[ElementType=obj ect](List[ElementType]):
...
Backward Compatibility

The three propositions are backward compatible.
Open Issues

Instead of adding a __specialize__ method, the __getitem__
method could be changed to allow additional signatures:

def __getitem__(sel f, *args, **kwargs): ...

Should other operators that square brackets be used for
specialization?
References

[1] Adding Optional Static Typing to Python -- Part II,
Guido van Rossum
http://www.artima.com/weblogs/viewpost.jsp?thread=86641

[2] Optional Static Typing -- Stop the Flames!, Guido van Rossum
http://www.artima.com/weblogs/viewpost.jsp?thread=87182
Copyright

This document has been placed in the public domain.

[Martin v. Löwis]

Nicolas Fleury wrote:

Hi everyone, I would to know what do you think of this PEP. Any comment
welcomed (even about English mistakes).

-1. I don't see the point of this PEP. Apparently, you want to define
parametrized types - but for what purpose? I.e. what are the specific
use cases for the proposed syntax, and why do you need to change the
language to support these use cases? I very much doubt that there are
no acceptable alternatives for each case.

IOW, whatever it is that you could do with this PEP, it seems you could
do this today easily.

Regards,
Martin

[Nicolas Fleury]

Martin v. Löwis wrote:

-1. I don't see the point of this PEP. Apparently, you want to define
parametrized types - but for what purpose? I.e. what are the specific
use cases for the proposed syntax, and why do you need to change the
language to support these use cases? I very much doubt that there are
no acceptable alternatives for each case.
Well, I'm using the alternatives. For example, where I work we have
built a small framework to create binary data to be loaded-in-place by
C++ code (it might be presented at next GDC (Game Developer
Conference)). It uses metaclasses and descriptors to allow things like:

class MyObject(LoadIn PlaceObject):
size = Member(Int32)
data = Member(makeArra yType(makePtrTy pe(MyObject2, nullable=True)) )
...

I know, it's not really Python, but still, defining functions like
makeArrayType and makePtrType is a pain. It is necessary to maintain a
dictionary of types (to avoid redundacy) and simple things like:

def makeType(someAr gument):
class MyObject:
someArgument = someArgument
return MyObject

are not allowed. So its ends up with something like:

__arrayTypes = {}
def makeArrayType(a rg1, arg2=someDefaul t):
if (arg1, arg2) in __arrayTypes:
return __arrayTypes[arg1, arg2]
renamed_arg1 = arg1
renamed_arg2 = arg2
class Array:
arg1 = renamed_arg1
arg2 = renamed_arg2
...
__arrayTypes[arg1, arg2] = Array
return Array

Does it qualify as an "acceptable alternative"? when it could have been:

class Array[arg1, arg2=someDefaul t]:
...

I probably should have put this example in the PEP.
IOW, whatever it is that you could do with this PEP, it seems you could
do this today easily.

The PEP validity is also very much influenced if optional static typing
is planned to be added to the language. I realize defending this PEP is
much harder without static typing and my use cases imply typing of some
sort anyway.

Regards,
Nicolas

[Bengt Richter]

On Sun, 07 Aug 2005 16:22:11 -0400, Nicolas Fleury <ni*****@yahoo. com> wrote:

Hi everyone, I would to know what do you think of this PEP. Any comment
welcomed (even about English mistakes).

PEP: XXX
Title: Specialization Syntax
Version: $Revision: 1.10 $
Last-Modified: $Date: 2003/09/22 04:51:49 $
Author: Nicolas Fleury <nidoizo at gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 24-Jul-2005
Python-Version: 2.5
Post-History:
Abstract

This PEP proposes a syntax in Python to do what is called in
this document "specialization ". It contains more than one
proposal:
- Extend square brackets syntax to allow a full call syntax,
using a __specialize__ method, similarly to the __call__
method.
- Extend function definition syntax to allow specialization
of functions.
- Parameterized types.
Motivation

In his controversial blog entry "Adding Optional Typing to
Python -- Part II" [1], Guido Van Rossum introduced the idea
of "parameteri zed types" in Python. The proposition was to
use [square brackets] rather than <pointy ones> to allow
prototyping with __getitem__ method. However, the __getitem__
method is not flexible enough. It doesn't support keyword
arguments and using multiple and default arguments can be pain,
since the only argument received would be a tuple. Calling
can also be error-prone if a tuple can be allowed as a first
argument. This PEP proposes to enhance square brackets syntax
to allow full-call syntax as with parenthesis.

Note that Guido dropped the idea, for now, of parameterized
types in a following blog entry [2]. This PEP introduces
parameterized types only as a last step, and focus more on
having a syntax to prototype them. This PEP can also serve
as a place to discuss to feature of specialization independently.

The term "specialization " is used in that document because
"parameteri zed functions" would sound like an already available
feature. As Guido pointed out [1], "generic" is neither a good
term. Specialization is a term in that case borrowed from C++.
The term alone is not perfect, since it refers to the action of
passing arguments to a "parameteri zed type" (or function) to
make it usable and a term must still be found to describe the
"unspeciali zed" type or function.

Another motivation to this PEP is the frequent usage in Python
of functions to create functions. This pattern is often used
to create callback functions and decorators, to only name these.
However, the fact that both the creation and the use is using
parenthesis can be confusing. Also, a programmer ends up naming
two functions, when only the creating one is called by name and
the created one is doing the job. Some programmers ends up
naming the creating function with the name they would want to
give to the created function, confusing even more the code using
it. To fix this situation, this PEP proposes a syntax for
function specialization.
__specialize __ Special Member Function. By "Member Function" do you mean anything different from "method"?

The first element of this proposal is the addition of the
__specialize__ special member function. The __specialize__
function can have the same signatures as __call__. When Any function can have any legal signature, so I'm not sure what you are saying.
defined, the definition of __getitem__ has no effect, and
__specialize__ will be called instead. What about subclassing and overriding __getitem__ ?

The language grammar is extended to allow keyword arguments
and no arguments. For example:

class MyObject(object ):
def __specialize__( self, a=4, b=6, *args, **kwargs):
pass here you can currently write
__getitem__ = __specialize__
although you have to remember that obj[:] and related slicing expressions
become legal and that obj[] does not, without a language sysntax change.
obj = MyObject()
obj[b=7, a=8, c=10]
obj[]

Note that when __specialize__ is defined, __setitem__,
__getslice__ and __setslice__ are still used as before.
The specializer Decorator

To explain the syntaxes proposed in this PEP, the following
decorator is used:

class Specializer:
def __init__(self, callableObj):
self.callableOb j ^^?? = callableObj ? self.__name__ = callableObj.__n ame__
def __specialize__( self, *args, **kwargs):
self.callableOb j(*args, **kwargs)

def specializer(cal lableObj):
return Specializer(cal lableObj)

It takes a callable and make it callable with square brackets
instead. Well, it wraps it, but the thing itself is still called as before from the wrapper,
so "it" itself is not "callable" with square brackets ;-)


Function Specialization

A common pattern in Python is to use a function to create
another function:

def makeGetMemberFu nc(memberName):
def getMember(objec t):
return getattr(object, memberName)
return getMember

foo(makeGetMemb erFunc('xyz'))
Either closures like the above or bound methods work for this,
so you just want more concise spelling?

The second element of this proposal is to add a syntax so
that the previous example can be replaced by:

def getMember[memberName](object):
return getattr(object, memberName)

foo(getMember['xyz'])

which is equivalent to:

@specializer
def getMember(membe rName):
def getMember(objec t):
return getattr(object, memberName)
return getMember

foo(getMember['xyz'])
Have you looked at currying? E.g.,
http://aspn.activestate.com/ASPN/Coo...n/Recipe/52549

Also, I made a byte-hacking decorator that is able to inject local presets
into a function itself (hence without wrapping overhead when used) or to curry
in another variation of the decorator. E.g.,

from ut.presets import presets, curry
@curry(memberNa me='xyz') ... def getMember(obj, memberName):
... return getattr(obj, memberName)
... o = type('',(),{})( )
o.xyz = 'This is object o attribute xyz'
getMember(o) 'This is object o attribute xyz' import dis
dis.dis(getMemb er) 1 0 LOAD_CONST 1 ('xyz')
3 STORE_FAST 1 (memberName)

3 6 LOAD_GLOBAL 0 (getattr)
9 LOAD_FAST 0 (obj)
12 LOAD_FAST 1 (memberName)
15 CALL_FUNCTION 2
18 RETURN_VALUE getMember.func_ code.co_argcoun t 1

Or the presets decorator can make the preset available without
having been a part of the original signature at all:
@presets(attnam e='xyz') ... def foo(obj): return getattr(obj, attname)
... foo(o) 'This is object o attribute xyz' dis.dis(foo) 1 0 LOAD_CONST 1 ('xyz')
3 STORE_FAST 1 (attname)

3 6 LOAD_GLOBAL 0 (getattr)
9 LOAD_FAST 0 (obj)
12 LOAD_FAST 1 (attname)
15 CALL_FUNCTION 2
18 RETURN_VALUE

As mentioned, these are byte code hacks. So they are pretty
fragile, version-portability-wise.


Class Specialization

The last element of this proposal is to add a syntax to pass
arguments to class creation:

class List[ElementType=obj ect](list):
...

This would be the equivalent to:

@specializer
def List(ElementTyp e=object):
class List(list):
...
return List

Note that the additional syntax is inserted before the
inheritance, different than what was initially proposed [1].
The reason is that inheritance can need the specialization
arguments, and it is more intuitive to use an argument
after its introduction:

class MyList[ElementType=obj ect](List[ElementType]):
...

Before I'd want to extend class syntax this way, I think I'd want to
explore some other aspects of class syntax as well, with more (and
more persuasive) use cases in view. Also more thought to what is done
when and whether the issue is to supply information into existing control
contexts or to modify control flow as well, to extend possibilities for
customized processing.

Backward Compatibility

The three propositions are backward compatible.
Open Issues

Instead of adding a __specialize__ method, the __getitem__ When you say "the" __getitem__ method, what do you mean? AFAIK the
method itself is an unrestricted function. It just happens that
binding it as a class attribute __getitem__ makes it get called
from code with square bracket access spellings. I think that's where
your changes to allow "additional signatures" would have to go. I.e.,
in generation of code from the "calling" syntax. To illustrate:
class C(object): ... def __getitem__(sel f, *args, **kwargs):
... return self, args, kwargs
... c=C()
c[1] (<__main__.C object at 0x02EF498C>, (1,), {}) c[1,2] (<__main__.C object at 0x02EF498C>, ((1, 2),), {}) c[:] (<__main__.C object at 0x02EF498C>, (slice(None, None, None),), {}) c[kw='key word arg'] File "<stdin>", line 1
c[kw='key word arg']
^
SyntaxError: invalid syntax

But here the problem is not in the __getitem__ method:
c.__getitem__(k w='key word arg')

(<__main__.C object at 0x02EF498C>, (), {'kw': 'key word arg'})

It's just that square bracket expression trailer syntax does not
allow the same arg list syntax as parenthesis calling trailer syntax.
method could be changed to allow additional signatures:

def __getitem__(sel f, *args, **kwargs): ...

Should other operators that square brackets be used for
specialization? Didn't quite parse that ;-) You mean list comprehensions? Or ??

References

[1] Adding Optional Static Typing to Python -- Part II,
Guido van Rossum
http://www.artima.com/weblogs/viewpost.jsp?thread=86641

[2] Optional Static Typing -- Stop the Flames!, Guido van Rossum
http://www.artima.com/weblogs/viewpost.jsp?thread=87182
Copyright

This document has been placed in the public domain.

Regards,
Bengt Richter

[Bengt Richter]

On Sun, 07 Aug 2005 17:20:25 -0400, Nicolas Fleury <ni*****@yahoo. com> wrote:

Martin v. Löwis wrote:

-1. I don't see the point of this PEP. Apparently, you want to define
parametrized types - but for what purpose? I.e. what are the specific
use cases for the proposed syntax, and why do you need to change the
language to support these use cases? I very much doubt that there are
no acceptable alternatives for each case.
Well, I'm using the alternatives. For example, where I work we have
built a small framework to create binary data to be loaded-in-place by
C++ code (it might be presented at next GDC (Game Developer
Conference)) . It uses metaclasses and descriptors to allow things like:

class MyObject(LoadIn PlaceObject):
size = Member(Int32)
data = Member(makeArra yType(makePtrTy pe(MyObject2, nullable=True)) )
...

I know, it's not really Python, but still, defining functions like
makeArrayTyp e and makePtrType is a pain. It is necessary to maintain a
dictionary of types (to avoid redundacy) and simple things like:

def makeType(someAr gument):
class MyObject:
someArgument = someArgument
return MyObject

are not allowed. So its ends up with something like:

I don't understand why you wouldn't give the function arg a different name
in the first place instead of via a temporary intermediary binding, e.g.,

def makeType(someAr gument_alias):
class MyObject:
someArgument = someArgument_al ias
return MyObject

__arrayTypes = {}
def makeArrayType(a rg1, arg2=someDefaul t):
if (arg1, arg2) in __arrayTypes:
return __arrayTypes[arg1, arg2]
renamed_arg1 = arg1
renamed_arg2 = arg2
class Array:
arg1 = renamed_arg1
arg2 = renamed_arg2
...
__arrayTypes[arg1, arg2] = Array
return Array
Or (untested, using new style class):

def makeArrayType(a rg1, arg2=someDefaul t):
try: return __arrayTypes[arg1, arg2]
except KeyError:
__arrayTypes[arg1, arg2] = Array = type('Array',() ,{'arg1':arg1, 'arg2':arg2})
return Array

(just re-spelling functionality, not understanding what your real use case is ;-)
Does it qualify as an "acceptable alternative"? when it could have been:

class Array[arg1, arg2=someDefaul t]:
...

I probably should have put this example in the PEP.

IOW, whatever it is that you could do with this PEP, it seems you could
do this today easily.

I agree with this, until I see some really persuasive use cases.

The PEP validity is also very much influenced if optional static typing
is planned to be added to the language. I realize defending this PEP is
much harder without static typing and my use cases imply typing of some
sort anyway.

I'll have to catch up with that. Have been very bogged down for a long while.

Regards,
Bengt Richter

[Nicolas Fleury]

Bengt Richter wrote:

__specialize_ _ Special Member Function.
By "Member Function" do you mean anything different from "method"?

No, I should have written method. C++ habit.

The first element of this proposal is the addition of the
__specialize__ special member function. The __specialize__
function can have the same signatures as __call__. When

Any function can have any legal signature, so I'm not sure what you are saying.

You're right, I should focus on the syntax change, to call __getitem__
(or __specialize__) automatically.

defined, the definition of __getitem__ has no effect, and
__specialize__ will be called instead.

What about subclassing and overriding __getitem__ ?

I have no problem with that. I even suggest it at the end of the PEP.

But don't you think the name "__getitem_ _" is not appropriate then?
here you can currently write
__getitem__ = __specialize__
although you have to remember that obj[:] and related slicing expressions
become legal and that obj[] does not, without a language sysntax change.
Yes, the PEP is about that syntax change.

class Specializer:
def __init__(self, callableObj):
self.callableOb j

^^?? = callableObj ?

Yes, "= callableObj" is missing.

A common pattern in Python is to use a function to create
another function:

def makeGetMemberFu nc(memberName):
def getMember(objec t):
return getattr(object, memberName)
return getMember

foo(makeGetMemb erFunc('xyz'))

Either closures like the above or bound methods work for this,
so you just want more concise spelling?

In the case of functions, yes. For functions, I guess the syntax is
much more useful is static typing is added, or planned to be added, in
the language. However, there's still use cases where it is useful.
Have you looked at currying? E.g.,
http://aspn.activestate.com/ASPN/Coo...n/Recipe/52549

And partial will be in Python 2.5 (PEP 309). Yes, I've look at it, but
in my use cases the created function correspond to a specific function
signature, so, for example, you always only want to specify the
"memberName " argument. Currying is nice, but since any argument can
supplied, the code is less self-documenting. But I used these in
day-to-day programming.

class MyList[ElementType=obj ect](List[ElementType]):
...

Before I'd want to extend class syntax this way, I think I'd want to
explore some other aspects of class syntax as well, with more (and
more persuasive) use cases in view. Also more thought to what is done
when and whether the issue is to supply information into existing control
contexts or to modify control flow as well, to extend possibilities for
customized processing.

What do you think of the example I post in a reply to Martin v.Lowis?

Instead of adding a __specialize__ method, the __getitem__

When you say "the" __getitem__ method, what do you mean? AFAIK the
method itself is an unrestricted function. It just happens that
binding it as a class attribute __getitem__ makes it get called
from code with square bracket access spellings. I think that's where
your changes to allow "additional signatures" would have to go. I.e.,
in generation of code from the "calling" syntax. To illustrate:

>>> class C(object): ... def __getitem__(sel f, *args, **kwargs):
... return self, args, kwargs
... >>> c=C()
>>> c[1] (<__main__.C object at 0x02EF498C>, (1,), {}) >>> c[1,2] (<__main__.C object at 0x02EF498C>, ((1, 2),), {}) >>> c[:] (<__main__.C object at 0x02EF498C>, (slice(None, None, None),), {}) >>> c[kw='key word arg'] File "<stdin>", line 1
c[kw='key word arg']
^
SyntaxError: invalid syntax

But here the problem is not in the __getitem__ method:
>>> c.__getitem__(k w='key word arg') (<__main__.C object at 0x02EF498C>, (), {'kw': 'key word arg'})

It's just that square bracket expression trailer syntax does not
allow the same arg list syntax as parenthesis calling trailer syntax.

I totally agree and that's what I mean. The formulation of the PEP is
wrong, I should almost not talk about __getitem__ since as you said it
can have any signature. The PEP is about extending [] syntax to call
automtically __getitem__ function with more complex signatures.
Should other operators that square brackets be used for
specialization?

Didn't quite parse that ;-) You mean list comprehensions? Or ??

I mean should angle brackets <> like in C++, or another operator, be
used instead?

Regards and thx for your feedback,
Nicolas

[Nicolas Fleury]

Bengt Richter wrote:

I don't understand why you wouldn't give the function arg a different name
in the first place instead of via a temporary intermediary binding, e.g.,

def makeType(someAr gument_alias):
class MyObject:
someArgument = someArgument_al ias
return MyObject

Because that would affect documentation and keyword arguments. Both the
constructed class *and* the function are exposed to the user, so it
needs to be coherent.

__arrayType s = {}
def makeArrayType(a rg1, arg2=someDefaul t):
if (arg1, arg2) in __arrayTypes:
return __arrayTypes[arg1, arg2]
renamed_arg1 = arg1
renamed_arg2 = arg2
class Array:
arg1 = renamed_arg1
arg2 = renamed_arg2
...
__arrayTypes[arg1, arg2] = Array
return Array

Or (untested, using new style class):

def makeArrayType(a rg1, arg2=someDefaul t):
try: return __arrayTypes[arg1, arg2]
except KeyError:
__arrayTypes[arg1, arg2] = Array = type('Array',() ,{'arg1':arg1, 'arg2':arg2})
return Array

(just re-spelling functionality, not understanding what your real use case is ;-)

Well, of course, but I didn't wrote the rest of the class definition;)

So I need a place to put the class definition. In the end, it looks
very much like the mess in the example. Maybe I'm missing a solution
using decorators. I've defined a few classes like that, and I can live
with it, but having a syntax to do it more easily, I would use it right
away.

I guess it can also be useful for people interfacing with COM or typed
contexts.

Regards,
Nicolas

[Kay Schluehr]

Nicolas Fleury wrote:

It is necessary to maintain a
dictionary of types (to avoid redundacy) and simple things like:

def makeType(someAr gument):
class MyObject:
someArgument = someArgument
return MyObject

are not allowed.

def makeClass(cls_n ame, **kw):
return type(cls_name,( ), kw)

MyObject = makeClass("MyOb ject",a=8)
MyObject <class '__main__.MyObj ect'>
MyObject.a

8

Regards,
Kay

[Nicolas Fleury]

Kay Schluehr wrote:

def makeClass(cls_n ame, **kw):
return type(cls_name,( ), kw)

MyObject = makeClass("MyOb ject",a=8)
MyObject

As said to Bengt, a place is needed to write the class definition.
There's no need for metaclass in that case:

def makeType(a, b, c=someDefault):
arguments = locals()
class MyObject:
pass # Complete definition here
MyObject.__dict __.update(argum ents)
return MyObject

Regards,
Nicolas

[Kay Schluehr]

Nicolas Fleury schrieb:

Kay Schluehr wrote:

def makeClass(cls_n ame, **kw):
return type(cls_name,( ), kw)

>MyObject = makeClass("MyOb ject",a=8)
>MyObject

As said to Bengt, a place is needed to write the class definition.
There's no need for metaclass in that case:

def makeType(a, b, c=someDefault):
arguments = locals()
class MyObject:
pass # Complete definition here
MyObject.__dict __.update(argum ents)
return MyObject

Regards,
Nicolas

I have to admit that i don't actually understand what you want? The
problems you try to solve seem trivial to me but it's probably my fault
and i'm misreading something. You might be correct that your PEP may be
interesting only if "optional static typing" will be introduced to Py3K
and then we will suddenly have an immediate need for dealing with
generic types so that the syntax can be reused for deferred functions (
the concept of "specialization " is usually coupled with some kind of
partial evaluation which doesn't take place somewhere in your proposal
). But i'm not sure if this makes sense at all.

Kay