On Mon, May 01, 2006, Brett Cannon wrote: > On 5/1/06, Aahz <[EMAIL PROTECTED]> wrote: >>On Mon, May 01, 2006, Brett Cannon wrote: >>> >>> But there are two things that I can't quite decide upon. >>> >>> One is whether a signature object should be automatically created >>> for every function. As of right now the PEP I am drafting has it >>> on a per-need basis and have it assigned to __signature__ through >>> a built-in function or putting it 'inspect'. Now automatically >>> creating the object would possibly make it more useful, but it >>> could also be considered overkill. Also not doing it automatically >>> allows signature objects to possibly make more sense for classes (to >>> represent __init__) and instances (to represent __call__). But having >>> that same support automatically feels off for some reason to me. >> >>My take is that we should do it automatically and provide a helper >>function that does additional work. The class case is already >>complicated by __new__(); we probably don't want to automatically sort >>out __init__() vs __new__(), but I think we do want regular functions and >>methods to automatically have a __signature__ attribute. Aside from the >>issue with classes, are there any other drawbacks to automatically >>creating __signature__? > > Well, one issue is the dichotomy between Python and C functions not > both providing a signature object. There is no good way to provide a > signature object automatically for C functions (at least at the > moment; could add the signature string for PyArg_ParseTuple() to the > PyMethodDef and have it passed in to the wrapped C function so that > initialization of the class can get to the parameters string). So you > can't fully rely on the object being available for all functions and > methods unless a worthless signature object is placed for C functions.
>From my POV, that suggests changing the C API rather than not having automatic signatures. That probably requires Py3K, though. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach _______________________________________________ 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
