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
{{ message }}
Repository navigation
Standardize result-attribute naming on MgVideo (e.g. ssm_fig → ssm_figure) #346
Partial progress: two of the oddballs were renamed as part of a bug fix (744169f), because storing the result under the method's own name shadowed the bound method and broke repeated calls: subtract is now stored as subtract_video and the sonomotiongram result as sonomotiongram_audio. The remaining renames (ssm_fig, motion_plot, ssm_combined, pixelarray, etc.) still need the deprecation-alias treatment and remain 2.0-scope.
Further partial progress: ssm_fig is done (ca9ff0e).
ssm() now stores its result as ssm_figure, with ssm_fig kept as a deprecated property alias that reads and writes the canonical attribute and warns. The show(key='ssm') lookup moved with it, since it resolves by attribute name out of the instance dictionary and a class-level property does not appear there.
The alias is a property rather than a second attribute deliberately: two plain attributes drift apart the moment either side is reassigned, and the point of keeping the old name is that a script written against it sees what the new code stored. Its getter also re-raises under the name that was asked for, so hasattr(v, "ssm_fig") is False on a video with no SSM rather than raising about an attribute the caller never mentioned.
That is the deprecation-alias pattern this issue calls for, so the remaining renames can follow the same shape when 2.0 comes around.
Still open here: motion_plot, ssm_combined, pixelarray, motiongram_x/y, videogram_x/y, and the 2.0 removal of the ssm_fig alias itself.
Activity
alexarje commentedon Aug 6, 2026
Partial progress: two of the oddballs were renamed as part of a bug fix (744169f), because storing the result under the method's own name shadowed the bound method and broke repeated calls:
subtractis now stored assubtract_videoand the sonomotiongram result assonomotiongram_audio. The remaining renames (ssm_fig,motion_plot,ssm_combined,pixelarray, etc.) still need the deprecation-alias treatment and remain 2.0-scope.alexarje commentedon Aug 22, 2026
Further partial progress:
ssm_figis done (ca9ff0e).ssm()now stores its result asssm_figure, withssm_figkept as a deprecated property alias that reads and writes the canonical attribute and warns. Theshow(key='ssm')lookup moved with it, since it resolves by attribute name out of the instance dictionary and a class-level property does not appear there.The alias is a property rather than a second attribute deliberately: two plain attributes drift apart the moment either side is reassigned, and the point of keeping the old name is that a script written against it sees what the new code stored. Its getter also re-raises under the name that was asked for, so
hasattr(v, "ssm_fig")isFalseon a video with no SSM rather than raising about an attribute the caller never mentioned.That is the deprecation-alias pattern this issue calls for, so the remaining renames can follow the same shape when 2.0 comes around.
Still open here:
motion_plot,ssm_combined,pixelarray,motiongram_x/y,videogram_x/y, and the 2.0 removal of thessm_figalias itself.alexarje commentedon Aug 22, 2026
Correction to the hash above: the commit was rebased onto #366 before pushing, so it is
9ef2a4f, notca9ff0e.Store the self-similarity result as ssm_figure, keeping ssm_fig as an…
Design: the road to 2.0, and what order the open issues get closed in
Type the five files carrying most of the mypy backlog, and fix what t…
Plan: declare MgVideo's result attributes, closing #346 and most of #350
Record the attribute rename and what it bought