Skip to content
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

Merged
merged 25 commits into from
Feb 1, 2023

Conversation

MarkGotham
Copy link
Contributor

No description provided.

@MarkGotham
Copy link
Contributor Author

... I've reviewed the attrs for ratioString and beatSequence and am pretty sure that:

  • that's a good basis for this comparison
  • these tests should work ...

@MarkGotham MarkGotham marked this pull request as draft October 10, 2022 19:28
@MarkGotham MarkGotham marked this pull request as draft October 10, 2022 19:28
@MarkGotham MarkGotham marked this pull request as draft October 10, 2022 19:28
@MarkGotham MarkGotham marked this pull request as draft October 10, 2022 19:28
Copy link
Member

@mscuthbert mscuthbert left a 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.

music21/meter/base.py Outdated Show resolved Hide resolved
music21/meter/base.py Outdated Show resolved Hide resolved
music21/meter/base.py Outdated Show resolved Hide resolved
music21/meter/base.py Outdated Show resolved Hide resolved
music21/meter/base.py Outdated Show resolved Hide resolved
@mscuthbert
Copy link
Member

But see also discussion on the 1454 first.

MarkGotham added a commit to MarkGotham/music21 that referenced this pull request Oct 11, 2022
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`?
@MarkGotham
Copy link
Contributor Author

MarkGotham commented Oct 19, 2022

Latest:

Possible remaining questions:

  • Do we want assertRaises on the comparison of different classes or is False good (as here)?
  • Basic __eq__ method in core seems to have been the missing link. Now fixed. Q: all and only the right checks there or something else needed?
  • mypy: remove bool from def __eq__(self, other) -> bool:? On both base and core? (Why does this fail on one and not the other?)

@coveralls
Copy link

coveralls commented Oct 19, 2022

Coverage Status

Coverage: 93.055% (+0.002%) from 93.053% when pulling c3958a0 on MarkGotham:TimeSig__eq__ into 9afb3bc on cuthbertLab:master.

... with thanks to coveralls ;)
@MarkGotham MarkGotham requested a review from mscuthbert October 19, 2022 12:32
@MarkGotham MarkGotham marked this pull request as ready for review October 19, 2022 14:05
music21/meter/base.py Outdated Show resolved Hide resolved
Comment on lines 421 to 427
def __eq__(self, other) -> bool:

if not super().__eq__(other):
return False

return True

Copy link
Member

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.

Copy link
Contributor Author

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.

@MarkGotham
Copy link
Contributor Author

Latest: the 3x equality attributes seem to cover all and only the right comparisons:

  • beatCount: slow 6/8 and fast 6/8 successfully treated as unequal
  • symbol: Cut vs 2/2
  • ratioString (which actually stands in for much more than just a string): 2+3 != 3+2.

See tests at the end of meter/tests for coverage and proof of this particular pudding ;)

Comment on lines 421 to 422
def __eq__(self, other) -> bool:

if not super().__eq__(other):
return False

return True
Copy link
Member

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.

Copy link
Contributor Author

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 simple pass
  • no def __eq__ but with equalityAttributes = () 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 ;)

Copy link
Member

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.

@mscuthbert
Copy link
Member

Hi @MarkGotham -- just a ping on this.

@MarkGotham
Copy link
Contributor Author

Hi @mscuthbert , @jacobtylerwalls , all

Thanks for the nudge.

Eureka!

Coming back to this fresh, I realise that the much-discussed and not resolved placeholder __eq__ method was a red herring and the issue was with a single test case that a pre-existing "Work in Progress" test that's out of scope. Specifically:

  • test case pre-existing this PR (was commented out as marked as WIP)
  • I thought it could now be included, so removed the comment marks
  • but actually I can't because it tests on a different class (MeterSequence).

BTW this is one of two such test case (pre-existing this PR, commented out, marked as WIP) -- the other one is on TimeSignature objects, is now included, and works fine.

So, in summary:

Copy link
Member

@mscuthbert mscuthbert left a 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

@mscuthbert mscuthbert merged commit a8ba6e4 into cuthbertLab:master Feb 1, 2023
MarkGotham added a commit to MarkGotham/music21 that referenced this pull request Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants