How generic is adapters.read_from_file() meant to be?

[aparna-d2]

From

OpenTimelineIO/src/py-opentimelineio/opentimelineio/adapters/__init__.py

Line 137 in 45c6cfd

return adapter.read_from_file(

it looks like any kwargs are passed on to the specific adapter's read_from_file() -> read_from_string() through **adapter_argument_map. However, the same kwargs are not accepted by all adapters (eg. rate, ignore_timecode_mismatch is accepted in cmx_3600, but not in say, otio_json)
If we try to pass defaults to opentimelineio.adapters.read_from_file() in an effort to keep the code generic (without detecting the file format), we get TypeError: read_from_string() got an unexpected keyword argument ignore_timecode_mismatch
I am a bit doubtful about whether this should be handled on the user end, or if opentimelineio.adapters.read_from_file() should handle it. Any opinions?

[ssteinbach]

The generic form of the call would be with no arguments - the formats the adapters convert to/from have different features and constraints, and therefore the adapters have different features and arguments to their read_from_* functions. Do you have more context on what you're trying to do?

[jminor]

Since the set of possible keyword arguments for each adapter is open-ended, and the set of adapters can be extended by plugin, it would be impossible to maintain consistency between these arguments across all adapters. So I think that code which passes these arguments in will need to know which adapter is being used, and pass only arguments that make sense. The adapters themselves should strive to work by default with no keyword arguments when possible.

A different way to do this would be to pass one or more bundles of arguments, keyed by the adapter name. For example: `otio.adapters.write_to_file(timeline, {'aaf': { ... }, 'edl': { ... }, 'xml': { ... }})" so that defaults per-adapter could be passed in safely, but does this really improve the situation? Doesn't the caller know the filename and therefore the intended adapter already?

[JeanChristopheMorinPerso]

We could build a system where the arguments are injected into the type hints at runtime based on the available plugins. I think that would be doable. This would help to discover which adapter support which arguments.