Nick Coghlan <ncogh...@gmail.com> added the comment:

Based on the python-dev thread [1], the proposed name for this API is now 
"types.new_class()".

This parallels the existing imp.new_module() naming scheme and avoids various 
problems with the idea of using a static method on type itself (descriptors on 
type behave strangely, and the type namespace is accessible through *all* type 
objects, which would be weird in this case).

Since types is a Python module, we now have to choose between 3 implementation 
strategies:
- reimplement in pure Python (my preferred choice)
- implement in terms of __build_class__ (would work, but may not be portable to 
other implementations and/or serves as a de facto promotion of __build_class__ 
up to being part of the language specification)
- move Daniel's existing operator module based solution over to a new _types C 
extension module (again, may not help other implementations)

The reason I find the idea of a pure Python reimplementation appealing is that 
it can then serve as a cross-check for any other implementations implementing 
PEP 3115 for their class statements.

[1] http://mail.python.org/pipermail/python-dev/2012-May/119318.html

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14588>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to