gaogaotiantian commented on code in PR #57702:
URL: https://github.com/apache/spark/pull/57702#discussion_r3764483852
##########
python/pyspark/sql/tests/connect/test_connect_basic.py:
##########
@@ -842,6 +842,15 @@ def test_select_expr(self):
.toPandas(),
)
+ self.assert_eq(
+ self.connect.read.table(self.tbl_name)
+ .selectExpr(("id * 2", "cast(name as long) as name"))
Review Comment:
This case is a bit different actually. This is really changing the current
behavior.
First of all, I think our type annotation should match our behavior - that
should always be the case. I don't think a "wrong" type annotation helps us in
any case. If we allow the user to pass that, we should declare it in the type
annotation. If we don't allow the users to do that, we should reflect it in our
code. It doesn't make sense to allow users to do it but refuse to say it
loudly. As far as I understand, we never deprecate anything. So if an API
supports certain input, we might just document it.
Therefore, if we already takes `list` and `tuple` - we should just say it.
Or maybe even use `Sequence` as the type annotation.
This case is special in a way that the existing code does not support
`tuple`, only list. The question here is whether we should support `tuple`.
Generally, I think we should try to be consistent across our APIs. We have a
lot of APIs that support multiple column inputs in a way that the columns can
be passed as individual columns, a list of columns or a tuple of columns. It
would be quite confusing to support a specific usage on some APIs but not
others.
Is there a concern about support tuple of columns for certain APIs?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
