-
-
Notifications
You must be signed in to change notification settings - Fork 32k
inspect.signature does not work for datetime classes #88784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Classes in the datetime module are implemented using __new__ with some named parameters. I want to be able to inspect their signature to know which are the names of the parameters it accepts like it works for most classes. However, this does not work for classes in the datetime module. I already mentioned this in https://bugs.python.org/issue40897 but now I am thinking this should be a separate issue so I am creating this one. An example is the class timedelta. It has as parameters days, seconds, microseconds, milliseconds, minutes, hours and weeks. If I run the following script trying different python versions for py in 36 37 38 39; do What I get is === Python 3.6.9 === (*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'>
=== Python 3.7.11 ===
(*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'>
=== Python 3.8.11 ===
(*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'>
=== Python 3.9.6 ===
(*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'> |
Doesn’t it do that with any built in function? Try Len or open, for example. I think that’s a feature, at least not a bug specific to date time. |
Sorry. I did not include what is the behavior for other classes. An example could be calendar.Calendar. In this case the signature gives: >>> from calendar import Calendar
>>> import inspect
>>> print(inspect.signature(Calendar.__init__))
(self, firstweekday=0)
>>> print(inspect.signature(Calendar))
(firstweekday=0) Note that the signature gives firstweekday which is the only init parameter. Calendar is not implemented with __new__ so getting the signature would be for object, that does not include named parameters. It also works fine when you implement a class with __new__. For example: >>> class MyClass:
def __new__(cls, paramA, paramB=1):
obj = object.__new__(cls)
obj.paramA = paramA
obj.paramB = paramB
return obj
>>> print(inspect.signature(MyClass.__new__))
(cls, paramA, paramB=1)
>>> print(inspect.signature(MyClass))
(paramA, paramB=1) I do think it is a bug specific to the datetime classes. |
You're right, it seems specific to built-in *classes* like those in datetime. We get the same with inspect.signature(int), since int is also a built-in class. I don't know who maintains inspect, but it's not me. :-( |
Also happens in python 3.10. === Python 3.10.0b4 === (*args, **kwargs)
(self, /, *args, **kwargs)
Traceback (most recent call last):
...
ValueError: no signature found for builtin type <class 'datetime.timedelta'> |
I am not sure if this affects all built-in classes, assuming that by built-in it means that >>> import inspect
>>> import pagexml
>>> pagexml.swigPageXML.PageXML.__class__.__module__
'builtins'
>>> print(inspect.signature(pagexml.swigPageXML.PageXML.__init__))
(self, pagexml_path=None, schema_path=None) |
Reproduced in Python 3.12.0a7.
|
Since this is a problem with how the C extension is configured, maybe we could make some workaround where it calls the python implementation signature? Or encode it by hand?
|
inspect.signature
#27177Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: