-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
partial now behaves like a method descriptor #125983
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
The reason why this change does not follow the letter of PEP-387 is because this was impossible. The added warning itself causes a breaking change. #125316 was caused not by this change, but by the code necessary to produce a warning. This is a catch-22 situation -- to produce a warning about the future turn of
|
While true that adding a warning itself is already a breaking change, actually implementing the behavior is an additional, different breaking change for people who relied on the behavior on partial - E.g. Or even better, don't introduce a random, unnecessary breaking change whos only mentioned benefit is keeping an already fundamentally flawed comparison alive a bit more. The fact that we have tests that are broken by this is not random - we actually find the behavior of partial as a non-method descriptor useful. And |
Why is that? The former does not necessarily imply the latter. It was decided for
I appreciate the inconvenience. But given the situation at hand, which is for (a) would be a fair amount of inconvenience and disruption in development pipeline in this direction. Does (b) have any complications beyond straight forward adaptation by wrapping in |
Considering the lack of reply, I'll close this one as |
I didn't reply because I don't know what more to say. This is an unnecessary break in backwards compatibility (i.e. it doesn't allow anything new) and I don't consider any of the mentioned arguments even relevant. |
A prior discussion with motivation was discussed in #121027 (comment). The reason for this change is due to the new presence of Placeholder, introduced in Python 3.14. Now, delaying this change would likely require delaying the introduction of However, considering how the release manager and other core devs considered this feature to be acceptable, I doubt there will be a revert. |
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Bug description:
This is an intentional change done in #121089, following #121027. That PR disregarded PEP-387 and breaks compatibility with less than a version warning (less than because the
FutureWarning
that was added was late in the python 3.13 release cycle)I don't know if there is much more to add to this bug report - this change should not have been done without a proper deprecation period and IMO a proper discussion outside of two github issues. It should be reverted for 3.14 and a deprecation warning be added instead, with the final change, if being done at all, the earliest in 3.16.
It also already caused other issues, at least #125316. The reason I noticed this is because it broke actual tests on a project I am maintainer on: lark-parser/lark#1480
CPython versions tested on:
3.14
Operating systems tested on:
Windows
The text was updated successfully, but these errors were encountered: