[ https://issues.apache.org/jira/browse/SPARK-34544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292987#comment-17292987 ]
Rafal Wojdyla edited comment on SPARK-34544 at 3/1/21, 4:40 PM: ---------------------------------------------------------------- 👋 [~zero323] {quote} it is more a dev utility than user a facing feature. {quote} We use mypy to type check our codebase, and we hit this issue as users, for an example of an issue see SPARK-34540 (which is just one case). Btw I could not find any documentation for the pyspark typing contributions (like in what cases new symbols should be added to public protocols, and why protocols are incomplete etc), I probably missed it, could you please point me towards it? {quote} As far as I am aware removing it doesn't resolve any of the problems described here {quote} Removing the {{DataFrameLike}} as the return type of the {{toPandas}}, would make mypy stop shouting about missing symbols (which are not part of {{DataFrameLike}}, but are in fact valid methods of pandas' {{DataFrame}}). This is obviously suboptimal since then it just becomes {{Any}}. An alternative is to add the missing symbols to the {{DataFrameLike}} as in SPARK-34540. But until pyspark release, how would we monkey patch that change in our projects? So in the end it sounds like we have a bunch of suboptimal ideas, how should we proceed? was (Author: ravwojdyla): 👋 [~zero323] > it is more a dev utility than user a facing feature. We use mypy to type check our codebase, and we hit this issue as users, for an example of an issue see SPARK-34540 (which is just one case). Btw I could not find any documentation for the pyspark typing contributions (like in what cases new symbols should be added to public protocols, and why protocols are incomplete etc), I probably missed it, could you please point me towards it? > As far as I am aware removing it doesn't resolve any of the problems > described here Removing the {{DataFrameLike}} as the return type of the {{toPandas}}, would make mypy stop shouting about missing symbols (which are not part of {{DataFrameLike}}, but are in fact valid methods of pandas' {{DataFrame}}). This is obviously suboptimal since then it just becomes {{Any}}. An alternative is to add the missing symbols to the {{DataFrameLike}} as in SPARK-34540. But until pyspark release, how would we monkey patch that change in our projects? So in the end it sounds like we have a bunch of suboptimal ideas, how should we proceed? > pyspark toPandas() should return pd.DataFrame > --------------------------------------------- > > Key: SPARK-34544 > URL: https://issues.apache.org/jira/browse/SPARK-34544 > Project: Spark > Issue Type: Bug > Components: PySpark > Affects Versions: 3.1.1 > Reporter: Rafal Wojdyla > Assignee: Maciej Szymkiewicz > Priority: Major > > Right now {{toPandas()}} returns {{DataFrameLike}}, which is an incomplete > "view" of pandas {{DataFrame}}. Which leads to cases like mypy reporting that > certain pandas methods are not present in {{DataFrameLike}}, even tho those > methods are valid methods on pandas {{DataFrame}}, which is the actual type > of the object. This requires type ignore comments or asserts. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org For additional commands, e-mail: issues-h...@spark.apache.org