When there is a MIB table who reuses index objects from another table, the index can be 'implied' in one table, but the same object can be not implied in the index of the other different table.
So when converting to/from OID, whether or not the length is present depends on the table for which it is used, it is not a property of the object itself.
See e.g. in the tests "snimpyReuseIndexTable" which is uses "snimpyIndexImplied" in the index, but is not "IMPLIED" in this table.
Coverage increased (+0.2%) to 88.505% when pulling 6597eff6908e78e1b433ef9aeff123b5da0200d4 on joostdetollenaere:master into 5766f13bee70b8dc880067942e1528e859cfd388 on vincentbernat:master.
When there is a MIB table who reuses index objects from another table, the index can be 'implied' in one table, but the same object can be not implied in the index of the other different table.
So when converting to/from OID, whether or not the length is present depends on the table for which it is used, it is not a property of the object itself.
See e.g. in the tests "snimpyReuseIndexTable" which is uses "snimpyIndexImplied" in the index, but is not "IMPLIED" in this table.