Guido van Rossum
Thu, 07 Nov 2002 11:39:12 -0500
> Any opinions on how to handle builtins? Should getargspec() return
> empty values or raise an error? The current version raises TypeError
> on anything that fails isinstance(object, types.FunctionType). The
> new version will support functions, bound methods, unbound methods,
> classes (which returns the contructor's arguments), and objects with
> a __call__() method (and will drop self as appropriate for all
> permutations of the preceding).
It should raise TypeError if it can't find the info requested.
> It doesn't seem right to me to raise an error for a builtin,
> especially if there will come a day when we *can* introspect the
> arguments for builtins. I'd rather return empty values and just
> document the fact that we don't have a way to return the argspec on
> builtins yet. Yay, nay, other?
Making something that currently raises TypeError return a useful value
is deemed backwards compatible. Making something that currently
returns one value return a different value is deemed incompatible
(even if the new value is more useful).
> Neither solution is entirely satisfactory. Is there no trick that
> could be employed to expose the argspec for builtins?
Many builtins have the argspec as the first line of their docstring.
If you can parse the common cases, I'd be happy to accept patches to
fix a few cases where the docstring lies or is otherwise unhelpful.
But you'd still have to watch out for docstrings that don't have this
info, as there's no way to fix all 3rd party extension modules.
--Guido van Rossum (home page: http://www.python.org/~guido/)