gh-95065: PoC: Argument Clinic: Support multiple '* [from ...]' deprecations #107742
Conversation
erlend-aasland
changed the title
|
I'm not sure this feature improvement is worth it; though this is a rough draft, it introduces a lot more complexity. After this experiment, I'm aligned to say that we drop the ball on multiple layers of deprecation, for now. If the need arises, we can pick up this ball again (and try to implement this slightly nicer). |
| @@ -5520,6 +5520,7 @@ test_deprecate_positional_pos1_len1_optional(PyObject *module, PyObject *const * | |||
| PyObject *a; | |||
| PyObject *b = Py_None; | |||
|
|
|||
| // Emit compiler warnings when we get to Python 3.14. | |||
There was a problem hiding this comment.
Whatever we decide w.r.t. the larger feature, the addition of these comments to the generated code seems like a nice enhancement by itself
There was a problem hiding this comment.
Can we think of any current or recent situations where a stdlib function is undergoing simultaneous deprecations for several parameters, with different removal dates for the different parameters? If this is isn't something that actually comes up that frequently, I'm inclined to say that the feature probably isn't worth the extra complexity.
|
Taking sqlite3.connect as an example, I'd much rather do all deprecations in one go, rather than spreading it out over years and years with deprecation warnings. Combining different kinds of deprecations (deprecated positional plus deprecated keyword) is another story, though, but that's OT for this PR. |
|
I'm abandoning this effort. There is no reason to follow this up unless there is a pressing need for it. |
|
I am currently working on In any case this feature is not necessary. We can just defer the change and turn parameters to keyword-only on the same later term. Nobody died from prolonging the deprecation period (I hope so). |
This is a rough draft! Proof-of-concept only.