OOOOH THATS SO USEFUL THANKS A LOT!

Python list slicing works like this:

list[start:stop:step]

Where start is the first index to visit, stop is the index before which we will stop, and step is how far to move at each step of the process.

When start isn't specified it defaults to 0, and when stop isn't specified it means we take the entire list after start. When step isn't specified it also defaults to 1.

Putting this all together, list[::-1] means "take the entire list, stepping backwards" - or, in simpler terms, reverse it!

Super Cool Solution! I haven't seen that "[::-1]" thing before can someone explain what that is plz?

The difference is that with the reversed method you get a result that you still need to convert to something so you can use it later on in the code. With the ::-1 method you get a final result that is ready to be used in your code, with this method you get a final result, with the reversed you get a tool to use.

Get ahead with the times, people! /j

While it's true that many composers use enharmonic equivalents for readability or to simplify transposition, there are cases where composers prioritize the functional role of chords and notes within the scale or harmonic context. In such instances, flats and sharps can coexist in the same score, and even double flats or double sharps may appear instead of their enharmonic equivalents. This approach ensures that the notation reflects the theoretical structure of the music, such as voice leading, chord functions, or adherence to a specific scale.

For example:

• In a C diminished 7th chord (C–Eb–Gb–A), the A is often written as Bbb in certain harmonic contexts to preserve its function as a 7th.
• Or in jazz, we have chords such as (C-D#-E-G-Bb), which is an altered chord that uses both sharps and flats. This is the Hendrix Chord.

So while readability is often a priority, there are musical contexts where strict adherence to theory takes precedence. It's fascinating how notation choices can vary depending on the composer's intent and the piece's complexity!

If I understand the concerns raised by users below, the main issues are:

• A single score usually does not contain flats and sharps (unless key changes etc.),
• A flat should usually transpose to a flat, and a sharp to a sharp.

The problem is that I am not familiar enough with the domain of music to know how much of a problem it is if the above "usually" are violated in a coding challenge :)

Separating sharps from flats in inputs, if done, should not be a problem because this does not affect solutions.
Forcing flats-to-flats and sharps-to-sharps would break solutions, but I would personally not worry much about this TBH. I think it adds an interesting twist, still in scope of the rank, and new solutions will appear quickly. I am not a fan of beding backwards too hard only to keep old solutions, if invalidating them would allow improvements in quality.

Suggestion: add combination of flats and sharps in input, and add additional input arg to expect output in either flats or sharps. Make that param optional for backward compatibility of existing solutions (if backward compatibility is even possible).

Yes I planned to add C# I was just trying to figure the extent to which I want to modify this kata to address domain issues reported below (I.e. sharps vs flats in inputs and outputs).

no issue

I would keep the issue open. It is not clear from description whether an "interval" goes up or down.

Transposing a single note means shifting its value by a certain interval.

EDIT: nevermind, the description states it:

This is using sharp notation, where '#' after a note means that it is one step higher than the note.

• Could use a C# translation, as the other kata got retired.
• Also, as the kata with better quality was retired, we should really improve quality on this one -> EDIT: open issues resolved

This kata was decided to stay.

Enabled in this fork