The following are links to additional questions that our community has asked about this exercise:
This list will contain other frequently asked questions that aren’t quite as popular as the ones above.
Currently there have not been enough questions asked and answered about this exercise to populate this FAQ section.
This FAQ is built and maintained by you, the Codecademy community – help yourself and other learners like you by contributing!
Not seeing your question? It may still have been asked before – try () in the top-right of this page. Still can’t find it? Ask it below by hitting the reply button below this post ().
After some frustrated toying, I replaced code w/ solution. It runs and prints “Eggs!”, but is still marked as incorrect. Unable to proceed and unsure of what to do.
Why can’t you use “#” to comment rather than the triple quotes? Don’t they do the same thing? The code already written into the terminal area (I’m unsure what you call the area where you type the code) has comments written with the # key, so it makes zero sense to me why it makes you use triple quotes.
If it is simply just wanting you to do that comment method vs the other, then why do previous units allow you to use different code that does the same thing i.e. in the pig latin project, you need to grab the every letter except the first. You’d type something like [1:len(variable)] which supposedly would grab “ariable” (pretending “variable” is stored in variable. But it also lets you do [1:(variable)]. Though, ironically enough, in that lesson, it wasn’t letting me finish it the way it taught, it only let me do it once I typed it the way it showed you could do in the “Hint” section.
'''...''' is for multiline comments, and when used at the very start of a function, for writing a docstring of the function that help() can access.
On another consideration, commenting out code, temporarily, is a common debugging and testing strategy during the build phase. In the end, all comments might best be removed if they are not absolutely necessary in a production or end use version. That is where the docstring comes in.
In any interactive shell, type,
>>> help(print)
or any other built-in, for that matter. They all have a docstring. Notice how it describes both syntax and common usage? That is how we might best document our function, as well.
One should take one’s own advice more, though. Pretty sure there are still of my repl’s out there that have commented lines all over the place to show the progression from one method to another. Really need to go back and clean those up.
I agree, This is still an issue. I had followed the example with this description: “”“Prints ‘Eggs!’ to the console.”“” and it still failed. It passed when I changed the comment to match the solution. I would argue that what I had initially was more descriptive and a better comment. It shouldn’t count how we describe our function as incorrect behavior. If you want to teach good habits of documenting code let us have whatever we want within the triple quotes. This is very frustrating to people new to coding and wanting to learn. They complete the task you are asking and you tell them that it is wrong because the comment isn’t what you were looking for to the exact character.