[Python-Dev] signature object issues (to discuss while I am out of contact)

[Brett Cannon]

On 5/1/06, Aahz <aahz at pythoncraft.com> 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.

-Brett