Using functools.partial to make functions not considered as methods when given as enum values no longer works · Issue #125316 · python/cpython · GitHub
This is because MyCallables.B is considered to be functools.partial(<function b at 0x756d7f0065c0>) on 3.13.0, when it used to be <MyCallables.B: functools.partial(<function b at 0x71f7cbc407c0>)> before.
This is something I've been using to allow function values in enums not to be considered methods, which I most likely got from this thread. In the example above, A would always be considered a method.
It seems like on 3.13.0, the "wrapper class" approach is the only one that works.
@serhiy-storchaka maybe my title was not well formulated. This is what my issue boiled down to in my mind but I realize this is not exactly my problem, my problem is with the behavior I laid out in the snippet.
It used to be that we could use partial in order to use a function as the value for an enum variant while still having that variant act like one. With the breaking change you mentioned this is no longer possible, the enum variant is considered to be the function itself. But that's just a consequence (maybe even unintended, I don't know).
At least there is still the wrapper class approach that works! I guess I'll just update the stackoverflow thread I mentioned in case people run into that.
#125361 should fix this for 3.13. It restores the old behavior of partial in enums and adds a runtime warning. In 3.14 the behavior will be changed in any case.
We tried to emit a warning about future behavior change, but adding a warning already changed the behavior in some cases.
@hacscred This kind of feedback isn't helpful--we don't intentionally break code, this is a regression. Please read PEP-387 for our backwards compatibility policy.
This kind of feedback isn't helpful--we don't intentionally break code, this is a regression. Please read PEP-387 for our backwards compatibility policy.
No, this is clearly wrong. #121089 was an intentional break in backwards compatibility, disregarding PEP-387 with the argument that "this will only rarely break code".
Activity
ericvsmith commented on Oct 11, 2024
@rhettinger
ZeroIntensity commented on Oct 11, 2024
Confirmed on current main as well, technically a 3.13 regression.
serhiy-storchaka commented on Oct 11, 2024
This is an intentional change, and it is documented. See #121027.
Using staticmethod() to set a callable attribute without making it a method is more common idiom.
bluthej commented on Oct 11, 2024
@serhiy-storchaka maybe my title was not well formulated. This is what my issue boiled down to in my mind but I realize this is not exactly my problem, my problem is with the behavior I laid out in the snippet.
It used to be that we could use partial in order to use a function as the value for an enum variant while still having that variant act like one. With the breaking change you mentioned this is no longer possible, the enum variant is considered to be the function itself. But that's just a consequence (maybe even unintended, I don't know).
At least there is still the wrapper class approach that works! I guess I'll just update the stackoverflow thread I mentioned in case people run into that.
bluthej commented on Oct 11, 2024
I should probably add that using staticmethod in that context doesn't do the trick.
serhiy-storchaka commented on Oct 11, 2024
As was mentioned in other answer, there is a better solution -- use enum.member() (I did not know about it!).
bluthej commented on Oct 11, 2024
Thanks for the tip! I had seen that answer but since it wasn't upvoted much I didn't try 😅
pythongh-125316: Fix using partial() as Enum member
serhiy-storchaka commented on Oct 12, 2024
#125361 should fix this for 3.13. It restores the old behavior of partial in enums and adds a runtime warning. In 3.14 the behavior will be changed in any case.
We tried to emit a warning about future behavior change, but adding a warning already changed the behavior in some cases.
ZeroIntensity commented on Oct 14, 2024
@hacscred This kind of feedback isn't helpful--we don't intentionally break code, this is a regression. Please read PEP-387 for our backwards compatibility policy.
[3.13] gh-125316: Fix using partial() as Enum member (GH-125361)
MegaIng commented on Oct 25, 2024
No, this is clearly wrong. #121089 was an intentional break in backwards compatibility, disregarding PEP-387 with the argument that "this will only rarely break code".
ZeroIntensity commented on Oct 25, 2024
Yes, but this specific case with Enum was a regression and was fixed for this case. If that PR is causing more problems, open a new issue.
Fix partial in enum for Python 3.13 (#1993)
conditions: Operation: support function as Enum member in python 3.13+