Closed Badiboy closed 3 years ago
Many thanks. This is a FullNode-only API implementation. I haven't planed to support TronGrid APIs.
How about adding a TronGridClient
?
This is a FullNode-only API implementation. I did not found any mention about it.
I haven't planed to support TronGrid APIs. Frankly speaking I'm very new to Tron, so I see no difference between FullNode API and TronGrid API. If look on methods and data structures - methods are simillar, data structures are common (for example - get_transactions, where all transactions have the same format as the one in get_trasnaction.
But you are the library owner. If you do not want to have grid support (definitely I see no reason why, but may be you see: I'm nood in Tron) - I'll make my own custom extension. I thought it it is better to extend public library. :)
TronGrid is a close-sourced API implementation and is maintained by the TronGrid team.
The URL prefix is /v1/
.
Since it is close-sourced, I prefer not to have it mess up with FullNode APIs. In addition, TronGrid APIs have a different error handling logic(e.g. HTTP error code for rate limit).
Thank you all the same. You're right, support of trongrid is a required feature. It will be introduced in tronpy v0.3.
How do you think about the following:
tronpy.trongrid.TronGrid
orTron.trongrid
property.cherry-picked your 63ec3925d4051b36cc458d2fea73004134b5bcb7 to fix type hints.😄
How do you think about the following:
- Add trongrid.py, so it can be accessed viatronpy.trongrid.TronGrid or
- Add TronGrid APIs to Tron.trongrid property.
I have no special oppinion about it. As for now, I just need list of address transactions, so I'll get them anyway. :)
OK, I'll implement it first.
Absolutely not urgent. I made a custom request, so I'm fine now. :)
And some minor comments