-
Notifications
You must be signed in to change notification settings - Fork 406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
__eq__
comparison on time signatures
#1457
Conversation
... I've reviewed the attrs for ratioString and beatSequence and am pretty sure that:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some changes requested -- the part about checking class is very important.
But see also discussion on the 1454 first. |
Notably, this means removing time signatures for now while they're problematic. See cuthbertLab#1457
cuthbertLab#1466 introduces a new `__eq__` syntax and highlights some failing tests on Time Signature as 'work in progress'. This commit implements that syntax and fixes (uncomments) those tests. Possible remaining questions: - Do we want `assertRaises` on the comparison of different classes or is False good (as here)? - all and only the right checks in `core`?
Latest:
Possible remaining questions:
|
... with thanks to coveralls ;)
music21/meter/core.py
Outdated
def __eq__(self, other) -> bool: | ||
|
||
if not super().__eq__(other): | ||
return False | ||
|
||
return True | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also not needed. If you're just returning the value of a super()
call, then there's no point in subclassing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok thanks. True in so far as the actual test is not needed ... but the method is not expendable. Something is needed here, perhaps just to give MeterTerminal some notion of equality. FWIW empty equalityAttributes tuple (equalityAttributes = ()
) doesn't work.
Latest: the 3x equality attributes seem to cover all and only the right comparisons:
See tests at the end of |
music21/meter/core.py
Outdated
def __eq__(self, other) -> bool: | ||
|
||
if not super().__eq__(other): | ||
return False | ||
|
||
return True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't understand this -- what does this help in the system? I don't know of any object that always compares True to every other object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mscuthbert .
Thanks for this. As I say, this odd little method is just a placeholder - not the final solution, but a demo/reminder that something is needed on this class and none of the following are acceptable alternatives:
def __eq__
with a simplepass
- no
def __eq__
but withequalityAttributes = ()
on the class instead - neither of those two.
Excuse the exploratory approach but I don't know why this behaves as it does - whether it's to do the new wider handling of eq you've started implementing, or something on meter.
In short, I'm just reporting on the behaviour I see for this case and what 'works' (i.e., what apparently is needed to get the musical tests returning the correct bools).
My hope is that having this oddity and discussion point helps us diagnose what's going on and replace it with something more plausible. Likely it will feed into your wider re-working of meter.
The rest seems to work well ... and without oddities.
Thanks for any ideas for a fix. Equally, just say if you want to drop this PR, e.g., if it's not a good time for it / doesn't fit with your root-and-branch reform of the meter trees ... pun intended ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's best to comment it out. I've never heard of an object where if OBJ == True
is the same as if OBJ == False
and if OBJ == 5
and if OBJ == 2
are all True. It leads to huge issues with using the obj in a hash situation.
Hi @MarkGotham -- just a ping on this. |
This test pre-dates this PR and turns out to be out of scope.
Hi @mscuthbert , @jacobtylerwalls , all Thanks for the nudge. Eureka! Coming back to this fresh, I realise that the much-discussed and not resolved placeholder
BTW this is one of two such test case (pre-existing this PR, commented out, marked as WIP) -- the other one is on So, in summary:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now. Thanks for groking the equityAttributes -- this PR really inspired making all that finally work. Will merge when the little edit passes
No description provided.