Python SDK ETA (extra characters to make the title longer than 15 characters...)

Clients
21

Can you still answer this final question? Thank you.

22

Hi.

I am not entirely sure I understand what you question is, but I will try to provide an answer.

So it is true that there are differences in the ā€œrawā€ API you get back from the node, and what the Rust SDK exposes. Some of the renaming is due to backwards compatibility, but I dontā€™ see that as an issue.

The exact type in the target language (Rust, Java) will have to be adapted to what makes most sense in that environment. In Java it will be something else. I agree it would be ideal if there wereā€™t differences such as account_amount and amount names, but these are because of backwards compatibility.

Regarding the ā€œnestingā€. It would be ideal if that was not there, I agree. But the only way to get ā€œstrongā€ typing in protobuf is to define these message types. And then that involve nesting. We chose to go down this route instead of using primitive types everywhere. It is a choice which has upsides and downsides. This is where an SDK can provide better experience than the raw bindings generated from proto files. And that is indeed what we do in our SDKs. We transform the raw responses to make them more ergonomic to use.

23

Although it may not feel that way, you have answered my question :slight_smile:

For now Iā€™ve decided to:

  1. decode/convert simple types directly to the desired format (ie. every type that has one property)
  2. only construct my own types for AccountInfo, BlockInfo and everything related to bakers, pools, staking, etc. Using my own types enables dot notation and type checking, which really helps.
  3. keep transactionSummaries as a dict (but single types found are again decoded/converted), as this is too much work to define my own types for this.

Thanks.

1 Like
24

Well good then :smiley:

Iā€™ll take being accidentally helpful :slight_smile:

25

On that note :slight_smile:

Iā€™ve since changed gears and are developing a full blown SDK, converting all types. Yes, itā€™s a lot of work, but hopefully itā€™s useful at some point in time.

Question: Right now, Iā€™m writing tests based on actual transactions that happened on mainnet. However, there are (many?) types of of (update) transactions that havenā€™t happened yet (or my search is broken).

How would you suggest I test my implementations for conversions I canā€™t find an actual transaction for on mainnet?

26

I can get to 100% test coverage for many of the methods, but not for accountTransactions, as I believe not all of them have occurred on mainnet up until now.

What would be a good strategy to test these? I can see 2 options:

  1. Generate transactions on Testnet that cover all accountTransaction types
  2. Mock protobuf output (not even sure if thatā€™s feasible).

How do the other SDKs approach this?

27

It is true that not all transactions have occurred on mainnet. Since we restarted testnet last year we also donā€™t have full coverage on testnet anymore.

Regarding how other SDKs approach it. I can say for the Rust one. That one was tested on testnet, both the previous one and the current one.

The previous testnet had full coverage of transactions, including coverage of most reasons for failure.

Regarding how you should approach it. Option 1 is the more reasonable. With option 2 you are going to have problems since not every valid protobuf message is possible in the sense, so you would be testing scenarios which are impossible.

Perhaps I can find the old testnet database and you could test it on that.

28

Thank you. How difficult would it be to re-generate transactions covering all possible accountTransaction types on current testnet (to make sure that in the event of another testnet reset these transactions remain available for SDK testing purposes?)?

29

Has there been any progress on this? I would love to test my python SDK on all possible transactions (including failed ones).

30

Any update on this? Thanks.