Context Navigation

Changes between Initial Version and Version 1 of Ticket #32548, comment 6

initial	v1
1	1	I suppose it's a semantics argument whether `Q(Exists...)` is untested if there's a test that runs that exact expression, but isn't solely checking that functionality.
2	2
3		My point is that `Q(("x", 1))` and `Q(x=1)` are equivalent, so it's impossible for the deconstruct to correctly recreate the original args and kwargs in all cases. Therefore, unless there's an argument for keeping the special case, it's better to consistently use args for both `Q(x=1)~~` and `Q(x=1, y=2~~)`.
	3	My point is that `Q(("x", 1))` and `Q(x=1)` are equivalent, so it's impossible for the deconstruct to correctly recreate the original args and kwargs in all cases. Therefore, unless there's an argument for keeping the special case, it's better to consistently use args for both `Q(x=1).deconstruct()` and `Q(x=1, y=2).deconstruct()`.
4	4
5	5	I point out `Q(Exists...) \| Q(Q())` to show that the fragility of the special case is problematic and hard to catch. An internal optimization for nested empty Q objects can cause conditional expression combination to fail. That's why I'd like this patch to be focused on removing the special case and making Q objects more robust for all inputs, rather than only adding support for expressions. Both would make my future work on Q objects possible, but the current patch would put django in a better position for future development.