Comments
Rajat Chopra
and C++ (and even non-ANSI C) have /* ... */ for multi-line. Does Python
have anything comparable?
Gerhard Häring
> Does anyone know if Python supports multi-line comments? I believe Java
> and C++ (and even non-ANSI C) have /* ... */ for multi-line. Does Python
> have anything comparable?
No.
To temporarily disable blocks of source code, you can use "if 0:". For
documenting functions, methods, classes and modules, you usually use
docstrings.
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Mark McEahern
> Does anyone know if Python supports multi-line comments? I believe Java
> and C++ (and even non-ANSI C) have /* ... */ for multi-line. Does Python
> have anything comparable?
Short answer: No.
Long answer:
Use the triple-quoted string; e.g.,
def add(x, y):
"""Return the sum of x and y."""
"""
Note: The first string in a method is considered the docstring.
This here
is effectively
a multi-line
comment.
Fancy, neh?
"""
return x + y
Cheers,
// mark
Erlend J. Leiknes
this is a comment
oh, see, another line!!! =)
"""
"Rajat Chopra" <ra...@cs.utexas.edu> wrote in message
news:Pine.LNX.4.33.02050...@vampire.cs.utexas.edu...
Pete Shinners
there is no multiline comment. sometimes you can 'cheat' this by using
multiline strings...
"""
myfile.py
used to create all manner of neat functions
blah(x,y,z)
changelog:
joe on 1-1-01: added neat funcs
mark on 1-2-01: removed neat funcs
"""
Mark McEahern
> Sure, but comments are basically free whereas the above creates
> an anonmymous string which has to be garbage collected.
Good point! Thanks.
By the way, in emacs with python mode, you can select a region and
comment/uncomment it. Commenting a block simply prepends ## to each line in
the block. Nifty!
Cheers,
// mark
Sean 'Shaleh' Perry
On 08-May-2002 Mark McEahern wrote:
> [Rajat Chopra]
>> Does anyone know if Python supports multi-line comments? I believe Java
>> and C++ (and even non-ANSI C) have /* ... */ for multi-line. Does Python
>> have anything comparable?
>
>
> Long answer:
>
> Use the triple-quoted string; e.g.,
>
> def add(x, y):
> """Return the sum of x and y."""
>
> """
> Note: The first string in a method is considered the docstring.
> This here
> is effectively
> a multi-line
> comment.
> Fancy, neh?
> """
> return x + y
>
Sure, but comments are basically free whereas the above creates an anonmymous
string which has to be garbage collected.
Most scripting languages only support single line comments (usually with #).
/*
* I am ANSI C, hear me fly!
* and FLY!
*/
is not all that different from
# blah
# blah
# blah
if you need the visual difference, use 2 #'s.
## blah
## blah
## blah
Thomas Heller
I know about comment-region, but how do I uncomment?
Thomas
Lawrence Oluyede
You should use this:
"""
this is a
multiline comment
"""
start and end the comment with three double-quotes
--
Lawrence Oluyede
rhy...@myself.com
Mark McEahern
> I know about comment-region, but how do I uncomment?
I just select Python | Uncomment region from the emacs menu. I'm not an
emacs wizard, so maybe there's a version issue that explains why you don't
have a Python item in your emacs menu while in python mode?
Cheers,
// mark
Thomas Heller
I was looking for a function like uncomment-region, but this
doesn't exist.
However, hitting C-c ? points out that I have to use
'C-u C-c #' or 'C-u M-x comment-region' for uncommenting.
Great!
Thomas
Philip Swartzleonard
def foo:
# Or if you are writing a comment, just make sure there's a blank
line above and below and write it all out on one line likt this, then
hit M-Q or whatever 'fill' is set to, and it will make it into something
like:
pass
def foo:
# Or if you are writing a comment, just make sure there's a blank
# line above and below and write it all out on one line likt this,
# then hit M-Q or whatever 'fill' is set to, and it will make it
# into something like <this>
pass
I removed the extra blank lines manually. Unfortuantly if you try to do
something like this without the extra padding
def foo:
# A comment that is longer than fill length
c=1
c=2
pass
You'll get
def foo: # A comment that is
longer than fill length c=1
c=2 pass
... Is there a way to make emacs ignore lines that wouldn't be
considered comments by the language when wrapping?
--
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com
Thomas Heller
"Philip Swartzleonard" <st...@pacbell.net> wrote in message news:Xns92087A57CBC...@130.133.1.4...
>
> I removed the extra blank lines manually. Unfortuantly if you try to do
> something like this without the extra padding
>
> def foo:
> # A comment that is longer than fill length
> c=1
> c=2
> pass
>
>
> def foo: # A comment that is
> longer than fill length c=1
> c=2 pass
>
> ... Is there a way to make emacs ignore lines that wouldn't be
> considered comments by the language when wrapping?
No answer from here :-(
The same happens with triple quoted strings, unfortunately.
Barry?
Thomas
Karl Pflästerer
>> By the way, in emacs with python mode, you can select a region and
>> comment/uncomment it. Commenting a block simply prepends ## to each
>> line in the block. Nifty!
> I know about comment-region, but how do I uncomment?
(describe-function 'comment-region) <- place cursor here and hit C-x C-e
,----[ C-h f comment-region RET ]
| (comment-region START END &optional ARG)
|
| Documentation:
| Comment or uncomment each line in the region.
| With just C-u prefix arg, uncomment each line in region.
| Numeric prefix arg ARG means use ARG comment characters.
| If ARG is negative, delete that many comment characters instead.
| Comments are terminated on each line, even for syntax in which newline does
| not end the comment. Blank lines do not get comments.
`----
bye
KP
--
Der wahre Weltuntergang ist die Vernichtung des Geistes, der andere hängt von
dem gleichgiltigen Versuch ab, ob nach der Vernichtung des Geistes noch eine
Welt bestehen kann.
Karl Kraus 'Untergang der Welt durch schwarze Magie'
Karl Pflästerer
> I removed the extra blank lines manually. Unfortuantly if you try to
> do something like this without the extra padding
> def foo:
> # A comment that is longer than fill length
> c=1
> c=2
> pass
> You'll get
> def foo: # A comment that is
> longer than fill length c=1
> c=2 pass
> ... Is there a way to make emacs ignore lines that wouldn't be
> considered comments by the language when wrapping?
I changed the value of `paragraph-start'. I did it like this:
(add-hook 'python-mode-hook
(lambda ()
(setq paragraph-start "[ \t\n\f#]")))
"[ \t\n\f]" is the default for this variable.
bye
KP
--
And has thou slain the Jabberwock?
Come to my arms, my beamish boy!
O frabjous day! Callooh! Callay!'
He chortled in his joy. "Lewis Carroll" "Jabberwocky"
Tim Peters
> Sure, but comments are basically free whereas the above creates
> an anonmymous string which has to be garbage collected.
Perhaps surprisingly, it does not. A little-known optimization (one of the
few the compiler does) is that Python throws away all string literal
statements, except for those in docstring positions. It does this whether
or not -O is enabled.
So
def f():
"This is saved -- it's a docstring"
"""Except for its effect on line numbers in tracebacks, this
string doesn't exist -- the compiler throws it away.
"""
return 3
Cute: A few years ago there was a debate about whether Python should
*start* doing this optimization. Guido eventually decided that it should.
I then had the joy of pointing out that it already did <wink>.
a-time-machine-in-every-pot-ly y'rs - tim
Terry Reedy
"Sean 'Shaleh' Perry" <shale...@attbi.com> wrote in message
news:mailman.1020875117...@python.org...
> Sure, but comments are basically free whereas the above creates an
anonmymous
> string which has to be garbage collected.
I once read, I believe, that free-floating (unbound) strings that do
not become doc strings are eliminated (in batch mode) during
compilation.
TJR
Sean 'Shaleh' Perry
On 08-May-2002 Tim Peters wrote:
> [Sean 'Shaleh' Perry]
>> Sure, but comments are basically free whereas the above creates
>> an anonmymous string which has to be garbage collected.
>
> few the compiler does) is that Python throws away all string literal
> statements, except for those in docstring positions. It does this whether
> or not -O is enabled.
>
thanks for clearing that up Tim. Not sure I like the idea of random strings
being used for comments, but at least they are reasonably cheap.
Sean 'Shaleh' Perry
yeah, Tim Peters made that comment a short while ago.
Alex Martelli
...
> thanks for clearing that up Tim. Not sure I like the idea of random
> strings being used for comments, but at least they are reasonably cheap.
Totally random strings would make very unlikeable comments -- how
can you be unsure about it? Just imagine the mishmash of letters,
digits, punctuation -- suitable for a Perl script perhaps, but surely not
for a Python comment.
OTOH, random strings generated with some cleverness *might* make
for interesting comments, admittedly. E.g.:
[alex@lancelot cb]$ python past.py
simple pixels update specific will png_set_compression_*() function into
and or computational data. combine & when used
either the bkgd (i.e. changes 8 were -
png_structp = documentation code the following keyword. which
Great when you have to code for a place whose styles specify mandatory
comments and some minimal amount of comment vs code, no? Of course,
you'll pastiche from a sample text appropriate to the program's subject.
This of course may be generated from a simple program such as:
import random
def findNgram(haystack, needle):
pos = 0
n0 = needle[0]
ln = len(needle)
lh = len(haystack)
while pos+ln <= lh:
try: where = haystack[pos:].index(n0)
except: return -1
pos += where
if haystack[pos:pos+ln]==needle: return where
pos += 1
class pastiche:
# any substantial file of English words will do just as well
ifn='/home/alex/down/qt-x11-free-3.0.3/src/3rdparty/libpng/libpng.txt'
data = open(ifn).read().lower().split()
def renew(self, n, maxmem=3):
self.result = []
for i in range(n):
# randomly 'rotate' self.data
randspot = random.randrange(len(self.data))
self.data = self.data[randspot:] + self.data[:randspot]
where = -1
# get the N-gram
locate = ''.join(self.result[-maxmem:])
while where<0 and locate:
# locate the N-gram in the data
where = findNgram(self.data, locate)
# back off to a shorter N-gram if need be
locate = locate[1:]
c = self.data[where+len(locate)+1]
self.result.append(c)
return ' '.join(self.result)
p = pastiche()
for i in range(4):
print p.renew(8)
If you write many programs on similar subjects it's much faster to prepare
and save the N-grams you require once and for all from a suitable corpus,
then pasticheing them can be much faster than this.
Alex
Sean 'Shaleh' Perry
On 08-May-2002 Alex Martelli wrote:
> Sean 'Shaleh' Perry wrote:
> ...
>> thanks for clearing that up Tim. Not sure I like the idea of random
>> strings being used for comments, but at least they are reasonably cheap.
>
> Totally random strings would make very unlikeable comments -- how
> can you be unsure about it? Just imagine the mishmash of letters,
> digits, punctuation -- suitable for a Perl script perhaps, but surely not
> for a Python comment.
>
You say many interesting things in the rest of this. However perhaps my intent
was not clear.
When I see:
# hi, you should never set the next line to 1
value = 0
versus:
"""hi, you should never set the next line to 1
value = 0
I prefer the obvious comment versus the string.
<snip>
BTW 'pastiche' means what?
Fernando Pérez
>> ... Is there a way to make emacs ignore lines that wouldn't be
>> considered comments by the language when wrapping?
>
> I changed the value of `paragraph-start'. I did it like this:
>
> (add-hook 'python-mode-hook
> (lambda ()
> (setq paragraph-start "[ \t\n\f#]")))
>
> "[ \t\n\f]" is the default for this variable.
>
> bye
> KP
>
THANK YOU!!!!!!
I'd been hating life on this little thing for a long time (well, never
intensely enough to really bother looking for a solution ;).
I've used emacs for years, but I've just never bothered to learn enough on how
to configure it to solve the few little quirks it still has for my taste.
But this one was a fairly nagging one for me, so I _greatly_ appreciate your
solution (I'm glad I stumled on this thread!)
cheers,
f.
Cameron Laird
Sean 'Shaleh' Perry <shale...@attbi.com> wrote:
.
.
.
>BTW 'pastiche' means what?
>
>
<URL: http://www.dictionary.com/wordoftheday/archive/2001/05/16.html >
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Philip Swartzleonard
*Was going to say pretty much the same thing, but was at school when the
chance would have presented itself*
Now I just have to remeber WTF to put it in my emacs stuff ... last time
I looked my config scripts were in about 8 different files...
Peter Hansen
Just confirmed this by examining a .pyc file. Doc-strings in the
module level and in a function were present, but free-floating
strings immediately following did not appear. Sounds like that
makes them fairly effective for commenting-out purposes, although
for real comments the octothorpe is still a better choice IMHO.
-Peter
Alex Martelli
...
> >> thanks for clearing that up Tim. Not sure I like the idea of random
> >> strings being used for comments, but at least they are reasonably cheap.
> >
> > Totally random strings would make very unlikeable comments -- how
> > can you be unsure about it? Just imagine the mishmash of letters,
> > digits, punctuation -- suitable for a Perl script perhaps, but surely not
> > for a Python comment.
>
> You say many interesting things in the rest of this. However perhaps my
> intent was not clear.
Or perhaps somebody was deadpanningly playing upon the "random" idea.
Hard to say, really.
> BTW 'pastiche' means what?
According to The American Heritage Dictionary of the English Language:
pas·tiche Pronunciation Key (p-stsh, pä-)
n.
A dramatic, literary, or musical piece openly imitating the previous works of
other artists, often with satirical intent.
A pasticcio of incongruous parts; a hodgepodge: ?In... a city of splendid
Victorian architecture... there is a rather pointless pastiche of Dickensian
London down on the waterfront?
(Economist).
[French, from Italian pasticcio. See pasticcio.]
Alex
Huaiyu Zhu
Does this really work for you? After I added this, M-q no longer considers
multiline comments as a single paragraph. It also wraps long comment lines
without adding new # signs. Maybe I have some other settings in .emacs that
are interfering with this?
Huaiyu
Bernhard Herzog
[Emacs python-mode problems with fill-paragraph (M-Q) and comments]
I ran into this as well. I couldn't find a simple solution, so I hacked
up complex perhaps not very elegant one. Starting out with the fill
function from the lisp-mode. Over time I extended it a bit and now it
handles strings as well.
Basically, it's a python-mode specific fill-paragraph-function, so put
something like (setq fill-paragraph-function 'python-fill-paragraph-new)
into your python-mode hook.
Bernhard
Here's the code.
(defun python-fill-comment (&optional justify)
"Fill the comment paragraph around point"
(let (;; Non-nil if the current line contains a comment.
has-comment
;; If has-comment, the appropriate fill-prefix for the comment.
comment-fill-prefix)
;; Figure out what kind of comment we are looking at.
(save-excursion
(beginning-of-line)
(cond
;; A line with nothing but a comment on it?
((looking-at "[ \t]*#[# \t]*")
(setq has-comment t
comment-fill-prefix (buffer-substring (match-beginning 0)
(match-end 0))))
;; A line with some code, followed by a comment? Remember that the hash
;; which starts the comment shouldn't be part of a string or character.
((progn
(while (not (looking-at "#\\|$"))
(skip-chars-forward "^#\n\"'\\")
(cond
((eq (char-after (point)) ?\\) (forward-char 2))
((memq (char-after (point)) '(?\" ?')) (forward-sexp 1))))
(looking-at "#+[\t ]*"))
(setq has-comment t)
(setq comment-fill-prefix
(concat (make-string (current-column) ? )
(buffer-substring (match-beginning 0) (match-end 0)))))))
(if (not has-comment)
(fill-paragraph justify)
;; Narrow to include only the comment, and then fill the region.
(save-restriction
(narrow-to-region
;; Find the first line we should include in the region to fill.
(save-excursion
(while (and (zerop (forward-line -1))
(looking-at "^[ \t]*#")))
;; We may have gone to far. Go forward again.
(or (looking-at "^[ \t]*#")
(forward-line 1))
(point))
;; Find the beginning of the first line past the region to fill.
(save-excursion
(while (progn (forward-line 1)
(looking-at "^[ \t]*#")))
(point)))
;; Lines with only hashes on them can be paragraph boundaries.
(let ((paragraph-start (concat paragraph-start "\\|[ \t#]*$"))
(paragraph-separate (concat paragraph-separate "\\|[ \t#]*$"))
(fill-prefix comment-fill-prefix))
;;(message "paragraph-start %S paragraph-separate %S"
;;paragraph-start paragraph-separate)
(fill-paragraph justify))))
t))
(defun python-fill-string (start &optional justify)
"Fill the paragraph around (point) in the string starting at start"
;; basic strategy: narrow to the string and call the default
;; implementation
(let (;; the start of the string's contents
string-start
;; the end of the string's contents
string-end
;; length of the string's delimiter
delim-length
;; The string delimiter
delim
)
(save-excursion
(goto-char start)
(if (looking-at "\\('''\\|\"\"\"\\|'\\|\"\\)\\\\?\n?")
(setq string-start (match-end 0)
delim-length (- (match-end 1) (match-beginning 1))
delim (buffer-substring-no-properties (match-beginning 1)
(match-end 1)))
(error "The parameter start is not the beginning of a python string"))
;; if the string is the first token on a line and doesn't start with
;; a newline, fill as if the string starts at the beginning of the
;; line. this helps with one line docstrings
(save-excursion
(beginning-of-line)
(and (/= (char-before string-start) ?\n)
(looking-at (concat "[ \t]*" delim))
(setq string-start (point))))
(forward-sexp (if (= delim-length 3) 2 1))
;; with both triple quoted strings and single/double quoted strings
;; we're now directly behind the first char of the end delimiter
;; (this doesn't work correctly when the triple quoted string
;; contains the quote mark itself). The end of the string's contents
;; is one less than point
(setq string-end (1- (point))))
;; Narrow to the string's contents and fill the current paragraph
(save-restriction
(narrow-to-region string-start string-end)
(let ((ends-with-newline (= (char-before (point-max)) ?\n)))
(fill-paragraph justify)
(if (and (not ends-with-newline)
(= (char-before (point-max)) ?\n))
;; the default fill-paragraph implementation has inserted a
;; newline at the end. Remove it again.
(save-excursion
(goto-char (point-max))
(delete-char -1)))))
;; return t to indicate that we've done our work
t))
(defun python-fill-paragraph-new (&optional justify)
"Like \\[fill-paragraph], but handle Python comments and strings.
If any of the current line is a comment, fill the comment or the
paragraph of it that point is in, preserving the comment's indentation
and initial `#'s.
If point is inside a string, narrow to that string and fill.
"
(interactive "P")
(let* ((bod (py-point 'bod))
(pps (parse-partial-sexp bod (point))))
(cond
;; are we inside a comment or on a line with only whitespace before
;; the comment start?
((or (nth 4 pps)
(save-excursion (beginning-of-line) (looking-at "[ \t]*#")))
(python-fill-comment justify))
;; are we inside a string?
((nth 3 pps)
(python-fill-string (nth 2 pps)))
;; otherwise use the default
(t
(fill-paragraph justify)))))
--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
MapIt! http://www.mapit.de/
Fernando Pérez
> Fernando Pérez <fper...@yahoo.com> wrote:
>>Karl Pflästerer wrote:
>>
>>>> ... Is there a way to make emacs ignore lines that wouldn't be
>>>> considered comments by the language when wrapping?
>>>
>>> I changed the value of `paragraph-start'. I did it like this:
>>>
>>> (add-hook 'python-mode-hook
>>> (lambda ()
>>> (setq paragraph-start "[ \t\n\f#]")))
>>>
>>> "[ \t\n\f]" is the default for this variable.
>>>
>>
>>But this one was a fairly nagging one for me, so I _greatly_ appreciate
>>your solution (I'm glad I stumled on this thread!)
>
> Does this really work for you? After I added this, M-q no longer considers
> multiline comments as a single paragraph. It also wraps long comment lines
> without adding new # signs. Maybe I have some other settings in .emacs that
> are interfering with this?
Yes, it works perfectly. Now I can have:
def f():
""" bla.... long (multiline)"""
# bla comments, long...
and hit M-q in the commment and the docstring, and they both get independently
lined up _without_ the surrounding code or eachother getting broken.
Absolutely perfect!
I used to constantly play the game of 'add whitespace above and below, hit
M-q, delete whitespace'. So I _really_ like this, and the solution poster has
earned my eternal gratitude ;)
Cheers,
f.
Huaiyu Zhu
>Yes, it works perfectly. Now I can have:
>
>def f():
> """ bla.... long (multiline)"""
> # bla comments, long...
>
>and hit M-q in the commment and the docstring, and they both get independently
>lined up _without_ the surrounding code or eachother getting broken.
>Absolutely perfect!
Strange. After typing (the comment is in one line but my mail client
is configured to restrict to 80 char)
def f():
""" bla.... long (multiline)"""
# bla comments, long... adsf as as dsa sad fsad fdsa fads fdsa fdsa \
dsa dsa dsa fdsa dafadf ads ads fdsa
and do M-q on the # line, I now get
def f():
""" bla.... long (multiline)"""
# bla comments, long... adsf as as dsa sad fsad fdsa fads fdsa fdsa dsa
dsa dsa fdsa dafadf ads ads fdsa
What kind of settings in .emacs would cause this?
Huaiyu
Fernando Pérez
Don't know, but I take some things back. I realized that the 'magic' settings
have one fatal drawback: they don't properly realign indented docstrings. So
I had to revert back to the old mode, with all its brokenness.
Sorry if my early cheering got your hopes up.
f.