Error in some code, python course

codecademy error

i think the picture is self explanatory, we start counting from zero, but after trying the right numbers i let the system give me the code so i can finally advance to the next lesson, but the numbers are obviously wrong, it just takes it as the correct answer because its what the system has as a premade proper answer.

No big deal here tho, i just hope this feedback is helpful and helps fixing it for future newcomers.

The numbers in the screenshot are right, not sure if that’s your code or the provided solution
(printing is a good way of verifying what the result is)

I suspect you had suitcase[2:3] which will only have one element

1 Like

take the variable middle for example, suitcase contains 6 strings, which we start counting from 0, meaning that the last string would be logically 5 syntax wise.

That variable was asking for the 2 strings in the midle of suitcase list which would be 2 and 3 (if we count the first one as 0) leaving 2 other strings on each side, at least thats my logic following what the course have taught me.

Edit: yes thats the provided code by codecademy.

Yes, the items at indexes 2 and 3 are the ones that you want.

The problem is that you only included ONE item.

1 Like

so i have to always put one number ahead of my final target? if that makes sense, like if i have a list of 4 strings and i want the second and third string it would be: variable = list[1:3] ?

Exclusive end, yes.

I can’t formulate an argument for why it’s better than inclusive end. All I can really say is that I don’t think it’s weird to use or in any way ugly, I don’t wish it was different (a beginner may rush to the conclusion that it’s wrong because it’s not exactly how they think right at the moment, without considering that the language designers were in a much better position to make a good decision about it)

I suspect that because a lot of things are 0-indexed, an inclusive end would result in more +1’s and -1’s in code, and that may be the whole reason for it. This can probably argued for in some convincing manner, just not by me

It’s impossible or near impossible to google for because everyone’s making up an explanation that they think fits, without necessarily being the right one

@appylpye do you have a convincing argument for this? Not just one that “somewhat fits” … like actual references to computing history or something

Maybe it just ends up being weird every time 1-indexing is attempted and so they fix it. There are languages that do that, I just haven’t used any. I kind of assume that works fine too though.

1 Like

I think it just doesn’t matter very much, and that what people are used to doing for counting isn’t what’s happening in programs anyway, that the things complete beginners might react to while trying to map their current way of thinking to programming is totally trivial and outweighed by having fewer -1’s and +1’s

See the following image …


The indexes beneath the series of cells that each represent a memory location mark the boundaries of the cells. With zero-based indexing, they start at 0 because the indexes are measuring across a quantity of memory units, whether those units be bits, bytes, words, or some other unit. At the beginning, we have not yet measured across anything, hence we have 0, just as with the beginning of a ruler or the bottom of a measuring cup.

Regarding slices, with an exclusive end, the indexes in a slice specifier, such as [3: 7] indicate the left and right boundaries of the group of cells that comprise the slice. The substring, or slice, 'GRAM' is bounded by index 3 to its left and by 7 to its right. As you noted, @ionatan, this neatens the math. The length, 4, of the slice is the difference between the indexes that bound it. That is to be expected, since the two indexes straddle the full breadth of the slice.

Edited December 17, 2017 to include discussion of zero-based indexing.

1 Like

Yeah I considered arguing about comparing it to a physical ruler, but felt that it’s a detail that compilers/interpreters can take care of and not enough reason why we’d label the locations between boxes rather than the boxes themselves. Together with an argument of cleaner notation and consistency between high and low level languages, I agree it’s in favour of 0-indexing, but not all that strongly. (notation, physical representation, compatibility being the arguments, they all feel like secondary concerns (as far as I’m concerned the physical representation is an implementation detail which I don’t wish to pay attention to in code unless intentionally considering hardware… it’s somewhat a valid argument by proximity (a person with domain knowledge for one is likely to have domain knowledge for the other), but secondary))

How about this:

Consider what happens when moving in negative direction from the start. If using 1-indexing then the first element in negative direction becomes 0, but 0 isn’t negative or positive. 0 doesn’t belong on either side, it belongs between the negative and positive side which makes it not a location of a box, but a location between boxes.

In order to not cause a gap in the numbering we need to include 0 and because that is between boxes we ought to address boxes by where they start, which for the first box is 0.

Remark: It’s a rare occasion (and usually illegal) to move in negative direction from the start, but as a matter of consistency it needs to be considered.

…I should take some math classes so I’m not just flailing my arms about these things. I’m so incredibly likely to get things very wrong.

And then, having decided that the locations between boxes are what we’re referencing, your argument for exclusive end bound makes a great deal of sense, that it’s the boxes between these locations, and again, cleaner notation


that table was very helpful actually, putting everything aside in this post, that one picture just gave me a wide open understanding of the topic i pointed out in the first place, thank you very much.

Aye, I went pretty far off topic in my annoyance at not being able to argue for something that every new programmer will encounter and has to accept.
Kind of like how I think it’s fine that the sky is blue, but I’m not ready to explain it. (And now I’ve got to go googling that, obviously)

1 Like