Function call params: add native support for hex address (int conversion)

[BlockDweller]

First of all, thanks for building this great library - I've just started using it recently and it has been of great help so far.

Just a minor inconvenience that I came across is with Cairo<>Python Serializer. If a user wants to call a contract function that receives an address as input, this address has to be provided as an integer. When trying to call with the more widely used hex string format, the call throws an error from the encode_shortstring function. This makes sense, because of Starknet only supporting strings up to 31 characters while the addresses are 66 characters. Even so, it would be much more practical if hex strings are natively supported in your library by handling this conversion in the background and I believe this would be fairly easy to implement.

Of course it is easy to work around this behaviour by converting address string to int before calling the function. However, I wanted to bring this up as an idea/discussion because this could be a frequent source of errors and is less intuitive from a user perspective (much easier to cross-check the 0x format for example with a block explorer etc. instead of converting back and forth between hex and int).

Let me know your thoughts or best practices to work with this. I could not find any reference in your docs or provided example code.

[cptartur]

Hey, thanks for the suggestions!

We've discussed this with the team, and the implicit shortstring conversions that are currently in place prevent us from adding handling for hex strings - consider this case: Someone passes a "0x1234", a valid hex, just a short one. We're unable to distinguish with 100% confidence if this was meant to be a shortstring we have to encode or a short hex value that should be directly converted to felt. Implicit shortstrings conversions are deprecated in the serializer rewrite, but until complete removal, this is not resolvable.

My recommendation would be to favor using integers over string hex with starknet.py. They are used extensively in all parts of the library to represent felts in objects returned by Client methods, method arguments etc.

[BlockDweller]

Hey, thanks for the swift response.
That all makes sense and I appreciate your explanation. Only one more thought I wanted to add: the conversion from hex address could still be handled correctly somehow like this: if len(str)>31 && str.startswith("0x") then convert to int(str, base=16).

But I'll just get used to the integer address format, no problem at all and nothing more to add to this discussion from my side :)
I also didn't know that the implicit short string conversion is going to be deprecated anyway.

[cptartur]

Hey, thanks for the swift response. That all makes sense and I appreciate your explanation. Only one more thought I wanted to add: the conversion from hex address could still be handled correctly somehow like this: if len(str)>31 && str.startswith("0x") then convert to int(str, base=16).

We did consider some logic like that. It would work with longer hex addresses, but with short ones, it'd be the same problem as I wrote above. We believe that consistent behavior is more important in this case.

But I'll just get used to the integer address format, no problem at all and nothing more to add to this discussion from my side :) I also didn't know that the implicit short string conversion is going to be deprecated anyway.

The version with deprecation just got released yesterday, so it makes sense you unaware of that 😅