Closed mgorny closed 1 month ago
CC @serhiy-storchaka
I added the release-blocker label to make sure this is addressed one way or another before RC1 on the 30th.
Reviewing the issue, I suspect functools.partial
may need further special-casing in inspect
for 3.13 (the addition of the descriptor method doesn't currently change its behaviour, but some of the inspect functions are already treating it as if the 3.14 change was already in effect)
In the backport PR, https://github.com/python/cpython/pull/121092/files#diff-b89cd06e4637abacb73f2500301ff979a67ad7ecbfa7cf151c7243715898d7eaL2558 adjusted _signature_from_callable
to avoid having the addition of __get__
change the reported signature, which was enough to keep CI happy, but it appears that doesn't cover the whole of the inspect
module when it comes to partial
object handling.
@serhiy-storchaka, will you be able to look at this before rc1?
Unfortunately, the only way to add a warning about a partial object being made a method descriptor in the future is to make it a method descriptor. We can make inspect.ismethoddescriptor()
lying about partial
objects, but this will not help the user code which check the __get__
method directly. I do not know how to break this loop.
What's the expected result in 3.14? Is partial()
there expected to be recognized as a routine, and not have a __name__
attribute? Ideally, is there some documentation that explains whether __name__
is expected on all routines or not?
Yes, not all method descriptors (and therefore not all routines) have the __name__
attribute. This always was so, you always should have a fallback.
partial
in ismethoddescriptor()
and tests for 3.13. #122219 adds corresponding tests for main branch.
Documentation
While investigating encode/starlette#2648, I've noticed that the behavior of
inspect.isroutine()
changed with regards tofunctools.partial()
.Please consider the following sample:
Prior to 3.13.0b3, it would evaluate to
False
. In newer versions, it evaluates toTrue
.A bisect points out that it changed as a result of 49e5740135670e04ae6da7e6f52dbe380655e0f1 (i.e. #121086). Neither the commit message, nor the news entry, hints anything about
inspect.isroutine()
behavior.Could you please clarify whether the change was intentional? And if it was, could we have it explicitly noted in the documentation?
Linked PRs