> Then I don't think it's a priority to try to get rid of it, and maybe > it should just stay.
I think it would be desirable to get rid of METH_OLDARGS. Ideally, this should already be possible, as all modules should have been changed to be explicit about their usage of METH_OLDARGS (rather than relying on the struct field defaulting to 0), this can be "verified" by running the test suite once and checking that all ml_flags have one of METH_VARARGS, METH_NOARGS or METH_O set. Then it would be possible to drop METH_VARARGS, declaring that a 0 value of ml_flags means the default, which is "arguments are passed as a tuple". As for the remaining 50 or so PyArg_Parse calls: most of them convert a single object to some C representation; it should be possible to use the proper underlying conversion function. For example: - dbm/gdbm convert using s#; this can be replaced with the buffer API. - the array module converts the values on setitem using PyArg_Parse; these can be replaced with PyInt_AsLong, except that PyArg_Parse also does a range check, which could be moved into a range-checking function in arraymodule. As for the case of timemodule: the surprising feature is that "(ii)" uses PySequence_Getitem to access the fields, whereas PyArg_ParseTuple uses PyTuple_GET_ITEM, so it won't work for StructSequences. Regards, Martin _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
