Cannot (de)serialize objects with optional fields

[lithp]

Parity uses a custom BlockDetails object with a very weird last field.

is_finalized is a boolean field with the following representation:

• A value of True is represented as a True boolean field: len(BlockDetails) == 5
• A value of False is represented as nothing: len(BlockDetails) == 4

Presumably they wanted to save a little space in the database by simply not saving this field.

I don't think it's possible to create a subclass of rlp.Serializable which handles this use-case.

[carver]

One option is a method dedicated to pattern matching and dispatching, used like:

sedes_options = (BlockDetails, ShortBlockDetails)
try:
  rlp_obj, sedes_idx = rlp.dispatch_decode(encoded, sedes=sedes_options)
except rlp.AmbiguousDispatchError:
  # multiple sedes were capable of decoding the rlp, so no way to know which one is correct
except rlp.MissingDispatchError:
  # None of the sedes could decode the rlp

assert sedes_index in (0, 1)  # identifies which serializer was used

where rlp.MissingDispatchError is a subclass of rlp.DecodingError

---

I think the logic of: "these two serializers are actually for the same thing and we should merge them" should not be in pyrlp. It's easy enough to wrap the above example to create that effect.

[carver]

Oof, looks like we need to support serializing structures that are sometimes lists and sometimes byte-strings, so this becomes relevant again. (see https://ethereum-magicians.org/t/eip-2718-typed-transaction-envelope/4355/59?u=carver )

Looking into options now...

[carver]

Actually, this is pretty straightforward to just implement by hand, and I'm not sure the generalized solution would have added much value here. Maybe just a new page in the docs. See a WIP example here: ethereum/py-evm#1980 Note how BerlinTransactionBuilder does all of this pretty quickly in a deserialize() method, which can then be used as a sedes class in rlp.decode().