jerryshao commented on PR #4824: URL: https://github.com/apache/gravitino/pull/4824#issuecomment-2323426485
> @Lanznx Thank you for your contribustions. > > > Hi @Lanznx thanks a lot for your contribution. I think the current PR is still super large for review. For this kind of large PR, I would suggest we have a design doc and break down into small subtasks, which will be easy to review and track. CC @noidname01 @xunliu to also take a look. > > There is no new design for the python client, it is just rewritten in the python programming language following the java client implementation. If we follow the initial java client way, one small PR step by step commit, then it may take us about the same time as the java client to finish the python client development, which I guess will be very long. And the java client keeps adding new features, then the python client keeps catching up. So I would suggest that the python client should be completed as soon as possible with the same features as the java client. I don't agree that we should be in a hurry to get everything merged in one PR and catch up with the Java client ASAP. 1. Though Python API is similar to Java, but there's still some things that need to be thought of, whether the design is Pythonic or not, how to express the Java implementation into Python smoothly, and whether we need a Python counterpart actually. The design doc also helps to figure out how much work we need to do. 2. Remember last time we check in the Python fileset support without review. There are many follow-up works done by @noidname01 to make it relatively workable. I don't want this to happen again, we need to review each PR one by one to make sure it is OK before merging. 3. We can never catch up with the Java API counterpart, because most of the engineers are not familiar with Python, they only implement the Java part and leave the Python part as a follow-up work, unless we have someone dedicated to the Python part. So even if we catch up for now, we will be delayed somehow in future. 4. A deep question is that do we need to have all the APIs implemented in Python. For example, like Table API, what is the typical usage scenario in Python world, how would people use it in Python? These problems should be carefully weighed before we actually do so. So that's why we need a design doc. Anyway, from my point, this Python table API work should have a design doc, a community discussion and vote, and a plan before the code works. That's also how the community works. -- 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]
