Added prettytable package code with licence

[SaiNikhileshReddy]

🚀 🚀 Pull Request

Checklist:

• My code follows the style guidelines of this project and the Contributing document
• I have commented my code, particularly in hard-to-understand areas
• I have kept the coverage-rate up
• I have performed a self-review of my own code and resolved any problems
• I have checked to ensure there aren't any other open Pull Requests for the same change
• I have described and made corresponding changes to the relevant documentation
• New and existing unit tests pass locally with my changes

Changes

I have added Pretty Table package to the hub by copying and adding licence to hub files. This package is being added directly into hub is to reduce package count and help this issue effectively.

[CLAassistant]

All committers have signed the CLA.

[SaiNikhileshReddy]

@davidbuniat I have added PrettyTable code to the hub. If this is merged, I can push the code to the pretty print issue.

Tagging @farizrahman4u @mikayelh

[SaiNikhileshReddy]

This PR adds backend code to print data in pretty tables. Below is an example of generated table using this PR code.

[farizrahman4u]

Sorry but this issue has already been addressed by #1543 .

[SaiNikhileshReddy]

@farizrahman4u This PR aims to solve the issues @davidbuniat has mentioned here.
My solution works without the usage of .summary() and also working on the function .schema() as described in the above issue.

[farizrahman4u]

@SaiNikhileshReddy I would still prefer @neel2299 's implementation as it does not add any additional dependencies nor does it copy the entire codebase of a library to hub repo (which is really bad for a simple feature like this). API wise, ds.summary() is more natural (similar to model.summary() in keras, but thats just api and can be done using your implementation too). If you want to make improvements to @neel2299 's implementation (which is already in main) without introducing additional dependencies that would be great!

[SaiNikhileshReddy]

@farizrahman4u Thanks for sharing the feedback and @neel2299 implementation is good.

I was aware of dependencies issues with external packages, but I was thinking in different perspective of having pandas like table generation which supports jupyter dataframe and even cli appearance without uisng external package within hub.

I contacted @davidbuniat about this and he asked me to integrate the code from the PrettyTable package as there were no dependencies to their implementation and the licence supports code modification.

It is my bad that I tried to add entire code instead of stripping unnecessary code for using internally in hub. I didn't want to reinvent the wheel again to generate table.

The implementation I was trying to do was having flexibility in generating tables for both overall dataset and for each tensor without calling ds.summary() by calling just ds and ds[tensor][1:10] like @davidbuniat mentioned in the examples of the issue.

I'll probably work on ds.schema() if the current implementation of ds.summary() is sufficiant.

Once again thanks for helping out. @farizrahman4u @mikayelh @davidbuniat

[farizrahman4u]

@SaiNikhileshReddy I do not understand the "without calling ds.summary() by calling just ds".. doesn't that involve just adding it to __str__ of dataset and tensor?

[SaiNikhileshReddy]

Yes, we can integrate __str__ directly into the ds. I was mentioning about using table code I suggested for both ds and for ds[tensor] which can even be used for any other purpose later.

[SaiNikhileshReddy]

I wanted to make it simpler for anyone working with tables in the future with standard API internally in the hub.

My main motivation for doing this was that @davidbuniat had mentioned in the issue to learn how pandas are implemented and try to source code for the hub. Instead of reinventing the table generation for quick completion of the problem.

[SaiNikhileshReddy]

As now the problem has been solved, I'll try to push the code for ds.schema() like I mentioned in the issue.

Thanks for valuable feedback : )