~Values must not be zero-length, and must not contain whitespace characters.~ Constraints vary per-field; see syntax.rst.
~Per planned fix to #147, all constructor arguments, including priority (but excluding dispname), should hold to this. No specific/special (viz., numeric-only) validation on priority.~
This is in actuality a breaking change to the DataObjStr and DataObjBytes instantiation behavior, even though it's ultimately adding a guard against the user making a DataObj and/or Inventory that will be broken for downstream use. Best to save it for a major version bump.
Should probably implement a safety hatch for users who really want to make invalid objects, in case this validation is wrong/incorrect or irrelevant to an unanticipated use case. Simplest approach is to have a flag to ignore errors? Maybe convert them into warnings?
Would probably be a good opportunity to try adding in hypothesis -- it shouldn't be too hard to define coherent properties to apply to each field.
Once the validation is in place, the valid-objects tests won't work properly any more. There will still be expect-valid and expect-invalid cases; just, the check will have to be implemented differently. For expected-valid, the dos instantiation should work, and the object should appear in the IFile.load() contents. For expected-invalid, the dos instantiation should fail, and the object should not appear in the IFile.load() contents.
~Values must not be zero-length, and must not contain whitespace characters.~ Constraints vary per-field; see
syntax.rst.~Per planned fix to #147, all constructor arguments, including
priority(but excludingdispname), should hold to this. No specific/special (viz., numeric-only) validation onpriority.~This is in actuality a breaking change to the
DataObjStrandDataObjBytesinstantiation behavior, even though it's ultimately adding a guard against the user making aDataObjand/orInventorythat will be broken for downstream use. Best to save it for a major version bump.Should probably implement a safety hatch for users who really want to make invalid objects, in case this validation is wrong/incorrect or irrelevant to an unanticipated use case. Simplest approach is to have a flag to ignore errors? Maybe convert them into warnings?
Would probably be a good opportunity to try adding in
hypothesis-- it shouldn't be too hard to define coherent properties to apply to each field.Once the validation is in place, the valid-objects tests won't work properly any more. There will still be expect-valid and expect-invalid cases; just, the check will have to be implemented differently. For expected-valid, the
dosinstantiation should work, and the object should appear in theIFile.load()contents. For expected-invalid, thedosinstantiation should fail, and the object should not appear in theIFile.load()contents.