Open thorwhalen opened 2 years ago
Here are some more cases where no single signature can be defined for a builtin (without wrapping the builtin):
bytearray(12) #this works
bytearray('word') #if string, needs a second argument 'decoding'
>>> TypeError: string argument without an encoding
There's a set up already that handles
map
,print
etc.It uses a dict that maps names to signatures, which is used if a signature is not found.
I'm not 100% comfortable in doing this since:
iter
could have two signatures:iter(iterable)
oriter(callable, sentinel)
.Even so, if we do have this convenient fallback, it's not catching everything because sometime objects don't have a
__name__
. Should we use a more flexiblename_of_obj
for this? Should we have this function also look for a name in the__doc__
(if so, we should check if all__doc__
of builtins start with the name of the object.And do we use what's in the doc as far as signatures or define a signature that might make more sense.
See
itemgetter
for example. Perhaps the(*keys)
signature might make more sense. But thenitemgetter(i, j,...)
produces anoperator.itemgetter
instance that is callable, but doesn't have a signature. The signature that would make sense for it might be(sequence)
(though note that all an input object needs to be here is "gettable", i.e. have a__getitem__
--Sequence
is the smallestcollections
type that is "gettable).So how do we (and do we in the first place) take care of such cases where a
type
doesn't have a signature, and it produces callable instances that don't have a signature either.signatures.py
takes care ofpartial
explicitly, because we consider it fundamental for doing functional programming. But what aboutitemgetter
,attrgetter
, etc. Is there a clean way we can cover many of these in a consistent way?Important: Here, we should NOT:
inspect.signature
would give us, unlessinspect.signature
raises an error. The only thing we want to do is do something useful (like returning a valid, usable, signature in cases whereinspect.signature
fails to do so.Related: issue #16.
Notes
inspect.signature docs mention (see Note):
Some callables may not be introspect-able in certain implementations of Python. For example, in CPython, some built-in functions defined in C provide no metadata about their arguments.
This led me to look into pypy. Namely, the source code of builtins, with the intention of parsing it to retrieve signatures to use in
i2.signatures
.Note that we still need to be on the look out for overloading situations that don't have a single signature: For instance:
Observe that some of the python function definitions (e.g. the builtin/operation module) have
space
as their first argument, which apparently should be ignored when retrieving the signature.The signature for
iter
inpypy
is:┆Issue is synchronized with this Asana task by Unito