add PyType_New()

[ericsnowcurrently]

BPO	14942
Nosy	@warsaw, @ncoghlan, @ericsnowcurrently
Files	PyType_New.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-05-29.02:28:35.716>
created_at = <Date 2012-05-28.23:56:23.512>
labels = ['interpreter-core', 'type-feature']
title = 'add PyType_New()'
updated_at = <Date 2012-05-30.21:13:10.620>
user = 'https://github.com/ericsnowcurrently'

bugs.python.org fields:

activity = <Date 2012-05-30.21:13:10.620>
actor = 'barry'
assignee = 'none'
closed = True
closed_date = <Date 2012-05-29.02:28:35.716>
closer = 'ncoghlan'
components = ['Interpreter Core']
creation = <Date 2012-05-28.23:56:23.512>
creator = 'eric.snow'
dependencies = []
files = ['25752']
hgrepos = []
issue_num = 14942
keywords = ['patch']
message_count = 6.0
messages = ['161820', '161838', '161849', '161850', '161851', '161855']
nosy_count = 3.0
nosy_names = ['barry', 'ncoghlan', 'eric.snow']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue14942'
versions = ['Python 3.3']

[ericsnowcurrently]

Nick Coghlan suggested[1] exploring an easier spelling for "type(name, (), {})" in the C API. I've attached a patch that adds a function that does so: _PyType_New(). It's "private" in the patch, but only because I am reticent to expand the API without solid feedback from the more experienced devs.

Even if I didn't get the implementation quite right (I'm relatively new to the C API), the patch at least demonstrates the concept. :)

[1] http://mail.python.org/pipermail/python-ideas/2012-May/015281.html

[ncoghlan]

I realised that with the addition of types.new_class(), that's fairly easy to invoke from C (no harder than any other Python function, anyway). Thus, no need to duplicate the functionality directly in the C API.

[ericsnowcurrently]

Presumably you mean something like this:

<examples>

PyObject *
PyType_New(PyObject *name, PyObject *bases, PyObject *ns)
{
    PyObject *type, *args, *newtype;
    PyInterpreterState *interp = PyThreadState_GET()->interp;
    PyObject *modules = interp->modules;
    PyObject *builtins = PyDict_GetItemString(modules, "builtins");
    _Py_IDENTIFIER(type);

    if (builtins == NULL)
        return NULL;
    type = _PyObject_GetAttrId(builtins, &PyId_type);
    if (type == NULL)
        return NULL;
    args = PyTuple_Pack(3, name, bases, ns);
    if (args == NULL)
        return NULL;
    newtype = PyObject_CallObject(type, args);
    Py_DECREF(args);
    return newtype;
}

or even:

PyObject *
PyType_New(PyObject *meta, PyObject *name, PyObject *bases, PyObject *ns)
{
    PyObject *args, *newtype;

    args = PyTuple_Pack(3, name, bases, ns);
    if (args == NULL)
        return NULL;
    newtype = PyObject_CallObject(type, args);
    Py_DECREF(args);
    return newtype;
}

and called with "PyType_New(&PyTypeObject, name, bases, ns)".

</examples>

If that's what you meant, I'm okay with that. Otherwise please elaborate. :)

[ericsnowcurrently]

And unless there were some performance reason, I agree that the route I took in the patch is overkill.

[ncoghlan]

No, I mean no new C API at all. Anyone that wants to dynamically create a new type from C in 3.3 can already just write their own code to make the appropriate types.new_class() call:

http://docs.python.org/dev/library/types#types.new_class

A simple example, ignoring refcounting:

   types_mod = PyImport_ImportModule("types");
   new_class = PyObject_GetAttrString(types_mod, "new_class");
   new_type = PyObject_CallFunction(new_function, "s", "MyClass")

And assorted variations thereof using the different PyObject_GetAttr* and PyObject_Call* functions.

[ericsnowcurrently]

Yeah, I'd meant that as an illustration of what I'd understood, rather than some other proposal for the C API. types.new_class looks really handy. Thanks for clarifying.