Deprecate the type argument of review request signals
Review Request #8896 — Created April 12, 2017 and submitted
This patch deprecates the
type
argument of thereview_request_closed
andreview_request_closing
signals, due to shadowing thetype
builtin. We still provide thetype
argument, but it is wrapped in a
lazy object that will emit a warning when casted to a unicode string. We
now include theclose_type
argument which takes the place of the old
type
argument. Usages and unit tests have been updated for this new
behaviour.
Ran unit tests.
Description | From | Last Updated |
---|---|---|
Typo in summary: rquest |
david | |
this file isnt supposed to be in the diff. |
brennie | |
Sooo the difficulty here is that if an extension does: review_request.close(type=..., ...) then things are going to break. The problem … |
chipx86 | |
Can you pass these as keyword arguments? It'll help with readability a lot. |
chipx86 | |
Here, too. |
chipx86 | |
This should have a .. deprecated:: |
chipx86 | |
Here, too. |
chipx86 | |
This would be great in Djblets :) |
chipx86 |
- Diff:
-
Revision 2 (+222 -30)
Checks run (2 succeeded, 1 failed with error)
Checks run (2 succeeded, 1 failed with error)
-
-
Sooo the difficulty here is that if an extension does:
review_request.close(type=..., ...)
then things are going to break. The problem is that if
**kwargs
is provided, and we try to check for it there, then it'll still break sinceclose_type
won't be supported.Hmm..
Not the end of the world, but would be nice to fix.
Perhaps we could say that
close()
will, by default, close as submitted. Then we can do that and have a**kwargs
that checks fortype
and overridesclose_type
?I think submitted is going to be far more common than discarded, so I wouldn't have a problem with this as a default.
-
-
-
-
-