Message160394
| Author |
ncoghlan |
| Recipients |
daniel.urban, eric.araujo, ncoghlan, r.david.murray |
| Date |
2012年05月11日.01:02:53 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1336698175.11.0.873349534992.issue14588@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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 |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年05月11日 01:02:55 | ncoghlan | set | recipients:
+ ncoghlan, eric.araujo, r.david.murray, daniel.urban |
| 2012年05月11日 01:02:55 | ncoghlan | set | messageid: <1336698175.11.0.873349534992.issue14588@psf.upfronthosting.co.za> |
| 2012年05月11日 01:02:54 | ncoghlan | link | issue14588 messages |
| 2012年05月11日 01:02:53 | ncoghlan | create |
|