How is the syntax for a multi-line string different from a string that has two additional quotes inside of it?
Answer
In our Codecademy editor, strings and multi-line comments do share the same color: yellow. However! They’re not the same. When Python sees three quotation marks (single ’ or double ”) before and after something, it knows to make that a comment, rather than run it as code, if it’s not preceded by assignment to a variable. To illustrate this point, take a look at the example below:
long_string = """
This is just a long string assigned to the long_string variable!
useful for paragraphs
or lines that are very long
"""
"""
This is a multi-line comment.
It spands multiple lines!
It has no variable before it that it is being assigned to,
so it is not a string like above.
"""
It’s probably worth noting that long/docstrings are evaluated as string literals depending on where they are in the code. If they are in the right docstring locations they are added to the __doc__ special dictionary. Otherwise they are ignored by the bytecode interpreter.
>>> def foo():
"""This is a
lengthy docstring that will be
parsed and bytecode interpreted
by Python.
"""
return '''foobar'''
>>> foo()
'foobar'
>>> foo.__doc__
'This is a\nlengthy docstring that will be\nparsed and bytecode interpreted\nby Python.'
>>>
Note that the return is treated as a normal string.
Essentially it’s a “comment” because it doesn’t translate to any op-code
Assignment does (even if the variable isn’t used later, python doesn’t optimize such things, not cpython anyway (the reference implementation, and also most commonly used))
So would the following be a more accurate description?
>>> def foo():
"""This is a detailed
docstring that will be parsed
and written internally to the
__doc__ attribute of its
function object.
"""
pass
>>> print (foo.__doc__)
This is a detailed
docstring that will be parsed
and written internally to the
__doc__ attribute of its
function object.
>>>
Talking about whether docstrings are added by opcodes? That isn’t an unused string, it’s not dead code, it does something. I don’t know whether an opcode is used to add it, but my guess would be yes
I’m not going to suggest it is the intended use, but we may be able to use docstrings to present preformatted text (the spacing, anyway). It can be printed directly, or stored in a variable and printed later.
See the the earlier post above for an example. A docstring is intended to document a function, and when it appears at the top of function scope it can be accessed, printed or even saved to a variable.
>>> def foo():
"""This is a detailed
docstring that will be parsed
and written internally to the
__doc__ attribute of its
function object.
"""
return foo.__doc__
>>> print(foo())
This is a detailed
docstring that will be parsed
and written internally to the
__doc__ attribute of its
function object.
>>>
It’s not necessary to be that explicit in our naming conventions. If we had to add _string to every variable things would get cluttered in no time. Simple is best when it comes to naming. We’re less interested in type, which is a code concern, than semantics which is a reader concern. What meaning or information is contained in the string is more of interest.