spanner.py backward compatible changes #1807
Conversation
…ts have an associated required offset and clientInfo (if not specified, behaves as before). (2) new API insertFirstSpannedElement (3) new API popPendingSpannedElements. Also a fix that saves/restores spanner element offset/activeSite around operations that clear them.
|
This is the second split-out PR from PR #1768 |
|
All merged, and it looks like the tests are passing. Ready for review. |
|
Argh. Gotta test those new APIs that no-one is calling yet. Hang on. |
There was a problem hiding this comment.
Hi Greg -- can you talk through your proposed contribution with another music21 user to help get down on paper what exactly the benefit to the library of this contribution is? I feel like I've tried many times to understand what is happening and I still don't see it, and I need to get to other projects until I do. Thanks.
|
Maybe I should discuss this with @jacobtylerwalls, since he has been in the MusicXML reader a lot. |
|
I've tried to explain carefully in the doctests exactly what is intended here, in terms of how these APIs have been used in the past (which still works) and how they can be used in the future (and why). I restored the old doctests to show that they still pass (although I tweaked the order of calls a bit to match the order of the "old-style" calls that come from xmlToM21.py). Then I added the new doctests, and enhanced them (and their comments) to show how a parser can use the new parameters to deal with the fact that sometimes there is no "next note" that is at the correct offset to start the spanner, so a SpannerAnchor should be used instead. The next PR will be the one that changes xmlToM21.py to take advantage of the new-style calls, to handle |
|
make it Just please show that the way things were working before will still work -- I don't normally need to know the offset of the pending assignment in order to get it. But if there are multiple pending I can free just one by offset? Just show that -- then it's a new feature. |
|
Ooops, I was editing my comment while you were commenting on my previous comment: Here's my new one again: I've tried to explain carefully in the doctests exactly what is intended here, in terms of how these APIs have been used in the past (which still works) and how they can be used in the future (and why). I restored the old doctests to show that they still pass (although I tweaked the order of calls a bit to match the order of the "old-style" calls that come from xmlToM21.py). Then I added the new doctests, and enhanced them (and their comments) to show how a parser can use the new parameters to deal with the fact that sometimes there is no "next note" that is at the correct offset to start the spanner, so a SpannerAnchor should be used instead. The next PR will be the one that changes xmlToM21.py to take advantage of the new-style calls, to handle |
|
I think this is ready for re-review now (assuming the tests pass, which they did locally). |
|
Oops, forgot to change the version number(s). All ready now. |
|
Hopefully the new doctests and description will make the benefit of this new feature clear. I am adding a feature that xmlToM21.py will use soon to import accurately |
|
Oh wow, changing version from 9.7.2a7 to 9.7.3 lowered coverage by 3 lines, because "a7" was not parsed. Before I made that change, coverage was actually increased (a very little) by this PR. |
3 participants
New features in spanner.py: (1) Let pending spanner element assignments have an associated required offset and clientInfo (if not specified, behaves as before). (2) new API insertFirstSpannedElement (3) new API popPendingSpannedElements. Also a fix that saves/restores spanner element offset/activeSite around operations that clear them.