triple quoted strings as comments

[dmh2000]

I recently complained elsewhere that Python doesn't have multiline
comments. i was told to use triple quoted strings to make multiline
comments. My question is that since a triple quoted string is actually
a language construct, does it use cause a runtime construction of a
string which is then discarded, or is the runtime smart enough to see
that it isn't used and so it doesn't construct it?

example

def fun(self):
"""doc comment
comment line 2
"""

x = 1
y = 2

"""does this triple quoted string used as a comment
cause something to happen at runtime beyond
just skipping over it? Such as allocation of memory for a string
or worse yet garbage collection? or not?
"""
z = x + y

....

dave howard

 

[mithrond]

as i know, the triple quoted string does cause a runtime construction,
and will not be discarded, and it's a benefit of python language.
here is sth. useful.
_http://diveintopython.org/power_of_introspection/index.html

best regard

 

[Peter Hansen]

I recently complained elsewhere that Python doesn't have multiline
comments. i was told to use triple quoted strings to make multiline
comments. My question is that since a triple quoted string is actually
a language construct, does it use cause a runtime construction of a
string which is then discarded, or is the runtime smart enough to see
that it isn't used and so it doesn't construct it?

Easy enough to find out. Put this in test.py:

'first module comment'
'another'

def func():
'first func comment'
'another'
print 'hi'
'last one'

'and last module comment'


Now do "import test" from the Python prompt, then exit the interpreter
and do "strings test.pyc" on the compiled bytecode.

(The short answer is only the first such comments are kept.)

-Peter

 

[=?iso-8859-1?B?QW5kcuk=?=]

I recently complained elsewhere that Python doesn't have multiline
comments. i was told to use triple quoted strings to make multiline
comments. My question is that since a triple quoted string is actually
a language construct, does it use cause a runtime construction of a
string which is then discarded, or is the runtime smart enough to see
that it isn't used and so it doesn't construct it?

example

def fun(self):
"""doc comment
comment line 2
"""

x = 1
y = 2

"""does this triple quoted string used as a comment
cause something to happen at runtime beyond
just skipping over it? Such as allocation of memory for a string
or worse yet garbage collection? or not?
"""
z = x + y

It seems to discard the second triple quoted comment (the first one is
kept around as a doc string).
I created two scripts, one with the second triple quoted string, the
other without. The compiled version is *almost* the same (one byte
difference which, if I am not mistaken, comes from the different
filename embedded in the .pyc file).

30/01/2006 09:34 PM 327 triple.py
30/01/2006 09:35 PM 359 triple.pyc
30/01/2006 09:34 PM 96 triple2.py
30/01/2006 09:35 PM 358 triple2.pyc
André

 

[Roy Smith]

I recently complained elsewhere that Python doesn't have multiline
comments.

Of course it has multi-line comments. They look like this:

# This is the first line
# and this is the second.

Why is that a problem?

 

[Terry Hancock]

I recently complained elsewhere that Python doesn't have
multiline comments. i was told to use triple quoted
strings to make multiline comments. My question is that
since a triple quoted string is actually a language
construct, does it use cause a runtime construction of a
string which is then discarded, or is the runtime smart
enough to see that it isn't used and so it doesn't
construct it?

example

def fun(self):
"""doc comment
comment line 2
"""

This is specifically a "docstring" so it remains attached as
an attribute of fun: fun.__doc__

x = 1
y = 2

"""does this triple quoted string used as a comment
cause something to happen at runtime beyond
just skipping over it? Such as allocation of memory
for a string or worse yet garbage collection? or
not?
"""

This string is really unused. It will produce a value when
processed the first time, but it's not bound so it gets
immediately garbage-collected. And it won't be there after
the module is byte-compiled. So, you lose a little time the
very first time the file is used (but that's technically
true for a regular comment too -- I think this loses you a
little more time). But it's pretty trivial in practice,
because every subsequent time, it's gone.

z = x + y

At least, this is how I understand it.

Cheers,
Terry

 

[Steve Holden]

I recently complained elsewhere that Python doesn't have multiline
comments.

Personally I think it's a win that you couldn't find anything more
serious to complain about

regards
Steve

 

[Duncan Booth]

example

def fun(self):
"""doc comment
comment line 2
"""

x = 1
y = 2

"""does this triple quoted string used as a comment
cause something to happen at runtime beyond
just skipping over it? Such as allocation of memory for a string
or worse yet garbage collection? or not?
"""
z = x + y

How to find out for yourself:
"""doc comment
comment line 2
"""

x = 1
y = 2

"""does this triple quoted string used as a comment
cause something to happen at runtime beyond
just skipping over it? Such as allocation of memory for a string
or worse yet garbage collection? or not?
"""
z = x + y

6 0 LOAD_CONST 1 (1)
3 STORE_FAST 2 (x)

7 6 LOAD_CONST 2 (2)
9 STORE_FAST 1 (y)

14 12 LOAD_FAST 2 (x)
15 LOAD_FAST 1 (y)
18 BINARY_ADD
19 STORE_FAST 3 (z)
22 LOAD_CONST 3 (None)
25 RETURN_VALUE
Further inspection shows that it hasn't even saved that second string as a
constant:
('doc comment\n comment line 2\n ', 1, 2, None)

 

[Jeffrey Schwab]

Personally I think it's a win that you couldn't find anything more
serious to complain about

+1 QOTW

 

[Magnus Lycka]

I recently complained elsewhere that Python doesn't have multiline
comments.

It seems you have a bad editor if it can't conveniently
add and remove comment markers for arbitrary blocks in
your source. (Maybe you just didn't find this feature.)

That every comment line begins with a special symbol just
adds clarity. It's a bonus. C++ introduced // as comment
symbol for this purpose (but was stuck with /* and */ due
to backward compatibility reasons). Ada, while otherwise
similar to Pascal, adopted -- to end of row instead of (*
and *) etc.

An editor that adds/removes '# ' in the beginning of each
marked line is fairly bullet proof. Adding e.g. /* to the
beginning of a block you want to comment out, & */ to the
end, breaks if you have /* */ style comments in the block!

 

[Roy Smith]

An editor that adds/removes '# ' in the beginning of each
marked line is fairly bullet proof. Adding e.g. /* to the
beginning of a block you want to comment out, & */ to the
end, breaks if you have /* */ style comments in the block!

/* */ also allows for some truly spectacularly bad coding practices. Not
long ago, I ran into some real-life code where a previous developer had
commented out about 50 lines of C++ code by just putting a /* at the top
and a */ at the bottom. I was tearing my hair out trying to figure out how
the code worked until I noticed what he had done.

 

[Roel Schroeven]

Roy Smith schreef:

/* */ also allows for some truly spectacularly bad coding practices. Not
long ago, I ran into some real-life code where a previous developer had
commented out about 50 lines of C++ code by just putting a /* at the top
and a */ at the bottom. I was tearing my hair out trying to figure out how
the code worked until I noticed what he had done.

That happened to me a few times. These days I use an editor with syntax
highlighting that shows comments in another color than code. That helps
tremendously.

 

[Jorgen Grahn]

Roy Smith schreef: ....

That happened to me a few times. These days I use an editor with syntax
highlighting that shows comments in another color than code. That helps
tremendously.

Syntax highlighting, same here. Plus version control so you can see who did
it, and make a mental note not to trust that person in the future ;-)

("#if 0" in C and C++ are better choices, but only marginally. Best is to
remove the code unless you are sure it's needed again soon. Works in all
languages.)

/Jorgen

 

[Volker Grabsch]

[...] developer had
commented out about 50 lines of C++ code by just putting a /* at the top
and a */ at the bottom.

[...]
("#if 0" in C and C++ are better choices, but only marginally. Best is to
remove the code unless you are sure it's needed again soon. Works in all
languages.)

However, I'd only advise to do this if you are using a revision control.
Otherwise, you'll end up having a lot of "backup" files hanging around
which are even worse than multi-row comments. Or, even worse: If you
don't create backup files before removing code ...


Greets,

Volker

 

[Jorgen Grahn]

[...] developer had
commented out about 50 lines of C++ code by just putting a /* at the top
and a */ at the bottom.

[...]
("#if 0" in C and C++ are better choices, but only marginally. Best is to
remove the code unless you are sure it's needed again soon. Works in all
languages.)

However, I'd only advise to do this if you are using a revision control.

But surely, everybody's using revision control these days?
(Feel free to smile at my naivety now ;-)

/Jorgen