You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have some enumerated types spread throughout the codebase but they are treated as simple classes (see TrackKind, NeighborGapPolicy, MarkerColor to name a few).
Since these are currently simple classes effectively defining constants, the typing can become loose and the fact that enums are expected can get lost. One example is in the opentimelineio.schema.Track docstring:
class Track(opentimelineio.core.composition.Composition)
Track(name=None, children=None, kind='Video', source_range=None, markers=None, effects=None, metadata=None)
The kind kwarg is actually opentimelineio.schema.TrackKind.Video.
In the case of NeighborGapPolicy the result is less readable because it maps to integers.
Python enum.Enum subclasses could be used to preserve and convey the typing. This may also add for nicer parity with the C++ implementation while keeping a pythonic api footprint and making possible values more discoverable to new API users.
Considerations:
For python 2.7 compatability, we'd need to introduce a dependency on enum34 (related, we should discuss allowing a dependency on six for other compatibility cases. See the HLS adapter and the six alternative).
This could be a breaking change if existing code in the wild is using the underlying primitives or have defined their own new values for them.
Do enums need to be versioned when new values are added or can we rely on the objects using the enumerations to include that in their schema versions (e.x. if we add a new TrackKind increment the Track schema version)?
The text was updated successfully, but these errors were encountered:
It looks like NeighborGapPolicy already transitioned to an enumeration via the bindings.
For TrackKind and MarkerColor, as time goes on I think we've clarified that these aren't enumerations, they're constants for commonly used strings. I think we're embracing the power in allowing people to define whatever MarkerColor or TrackKind they need - most times one of the constant values from those classes will work though.
We have some enumerated types spread throughout the codebase but they are treated as simple classes (see TrackKind, NeighborGapPolicy, MarkerColor to name a few).
Since these are currently simple classes effectively defining constants, the typing can become loose and the fact that enums are expected can get lost. One example is in the
opentimelineio.schema.Track
docstring:The
kind
kwarg is actuallyopentimelineio.schema.TrackKind.Video
.In the case of
NeighborGapPolicy
the result is less readable because it maps to integers.Python
enum.Enum
subclasses could be used to preserve and convey the typing. This may also add for nicer parity with the C++ implementation while keeping a pythonic api footprint and making possible values more discoverable to new API users.Considerations:
enum34
(related, we should discuss allowing a dependency onsix
for other compatibility cases. See the HLS adapter and the six alternative).TrackKind
increment theTrack
schema version)?The text was updated successfully, but these errors were encountered: