Closed theeldermillenial closed 3 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 83.98%. Comparing base (
2bb4820
) to head (b7756ca
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Thanks for the change. Could you add a unit test (also as an example) where RawPlutusData
would be used when deserialized?
It is (and was) actually possible to use Datum
as type for arbitrary data in OpShin and AFAIK also in PyCardano. Could you check what difference there is to using RawPlutusData?
@nielstron The issue is that parsing did a hard check on types. You could pass in PlutusData
as a type, but it would throw an error because of constructor id. It used to be that you could use typing.Any
, and it would just parse whatever was there, including using RawPlutusData
to parse a datum. That seems to have changed in Python 3.11+.
I am not talking about PlutusDatum
but about Datum
To my knowledge, there is no Datum
class in pycardano. I don't use OpShin (yet), so I haven't tried doing that.
Even if there were a Datum
class, it's not defined in the primitive types and theres an explicit type check here:
Sorry if I'm misunderstanding what you're saying.
Some contracts are starting to include forward datums, where a field could contain an arbitrary datum that will be passed on to a subsequent address.
This requires the ability to support arbitrary plutusdata.
In Python <= 3.10, it was possible to pass in
typing.Any
to a field, but starting inPython 3.11
and beyond, it is no longer possible.This PR adds
RawPlutusData
to the list of available of PlutusData primitives that can be used for a field.