Closed mwufi closed 3 years ago
The reason for conversion is because python types and cadence types don't match. The conversion could be implicit for a string, or for something like array types, but it quickly becomes more complicated when you are trying to convert numbers. Is the python number you are sending a Int
or a Int64
or a UInt32
. For this reason I decided that it would be better to just do all cadence type conversion explicitly for now.
This does bring up something I haven't given much thought yet: If the sdk could know what type the cadence argument in the script/transaction are, a lot more implicit conversion could be done.
This would require parsing the script/transaction, which is something I would like to look into in the future, but doing so for every scripts/transactions might slow things down.
So I noticed in this code it sticks to a pretty explicit instantiation of the arguments
What's the pros/cons of this vs trying to implicitly infer this from the arguments? So you can imagine