Zitat von Michael Urman <[EMAIL PROTECTED]>: > On 3/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > How would this be accomplished - by a function with a ton of optional > templated arguments?
That's how I would do it. Actually, I would have PyArg_ParseTuple overloaded with different numbers of arguments, say 0..64. Each of them would be a template. > Only true when the rules are consistent with what smart pointers or > the like do. When there's more than a single rule, this goes out the > window because you have to use the correct smart class... Sure. You have to use PyObject* now, so changing to usage of PyObject_ptr wouldn't be that bad. Remember, we are talking about extension modules *to python* here. > ...and exceptions make it impossible to not use smart classes. Since > there isn't a nested level of C for each function call in Python, I > don't see how exceptions in the implementation language would help > exceptions in Python. Do I misunderstand your point, or is there some > really cool trick I'm missing? Instead of checking for a NULL return value on all functions, a Python exception could be expressed (on the C++ stack) as a C++ exception. So instead of writing n = PyString_FromString(name); if (n == NULL) return NULL; for (ml = methods; ml->ml_name != NULL; ml++) { if ((ml->ml_flags & METH_CLASS) || (ml->ml_flags & METH_STATIC)) { PyErr_SetString(PyExc_ValueError, "module functions cannot set" " METH_CLASS or METH_STATIC"); Py_DECREF(n); return NULL; } v = PyCFunction_NewEx(ml, passthrough, n); if (v == NULL) { Py_DECREF(n); return NULL; } if (PyDict_SetItemString(d, ml->ml_name, v) != 0) { Py_DECREF(v); Py_DECREF(n); return NULL; } Py_DECREF(v); } Py_DECREF(n); you would write n = PyString_FromString(name); for (ml = methods; ml->ml_name != NULL; ml++) { if ((ml->ml_flags & METH_CLASS) || (ml->ml_flags & METH_STATIC)) raise new PyExc_ValueError(PyExc_ValueError, "module functions cannot set" " METH_CLASS or METH_STATIC"); v = PyCFunction_NewEx(ml, passthrough, n); PyDict_SetItemString(d, ml->ml_name, v); } > (To explain my bias, I'm against the idea of the C++ rewrite as I also > fail to see the advantages outweighing the disadvantages, especially > in light of the amount of rewriting necessary to see the "advantages" > cited so far.) That's why I'm explaining the advantages to you. I'm not saying Python 3 should be written in C++, I'm only saying that doing so would have not just disadvantages. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com