import string
print string.joinfields( [
'You can always join long lines together',
'using string.joinfields ... Like this! ',
'I think this is just a readable as any',
'of the other alternatives.' ],
'\n' )
And points out one misfeature of automatic concatenation: I would
guess that I drop commas in lists much more frequently than I drop
"+" or other operators. Auto-concatenation would induce a bit more
confusion for those errors. In function argument lists, what is now
a syntax error would become wrong number of arguments, unless it was
a varargs function, in which case it would silently do the wrong
thing!
I would rather see generalized optimization of constant expressions.
( several have pointed out that that is not as easy to do. )
print "I would rather see further extension of the cases\n" +
" where a backslash is optional. The backslash at the\n" +
" end of the line is more anoying to me that the '+' is.\n" +
"( although the embedded backslash-newline's DO get on my nerves! )"
The above is only a slight improvement. Mostly where I would like to
see this is in long boolean if's. It would be nice if 'and' and 'or'
would not require a backslash to continue on a new line.
I would like a begin/end comment character similar to C's "/* */" .
The topics of literate programming, and online self documentation
have been raised in the past. The inability to have blocks on
comments without leading "#" chars get in the way for both of these.
# \
And comments don't continue, \
so this generates an error.
And even if legal: trading a required leading "#" for a required
trailing backslash is no win!
One idea I kicked around for a while, and then rejected, was to add
an explicit program end statement, so that a file could have a data/
text/documentation area at the end. ( The filename and line number
are available as function attributes, so it's quite simple to make
a function that reads in the text below itself. )
Maybe better that either of those, would be to make Python
"html-smart". Define a tag for python code, and if the file
begins with a bracketed html code, skip to the python-code
section. However, this doesn't work with unix
"#!/usr/local/bin/python" executables.
Maybe allow "#!/usr/local/bin/python" to be replaced with
"#!/usr/local/bin/pyfilter" - which would be the literate
programming code stripper. Then import would have to be
modified to pass the code thru the filter. ( Can this be
supported for Dos and Mac ??? )
I'm launching all of the above ideas without having thought out
all of the implications myself - mostly because I consider
better comment and online-documentation and literate programming
support much more important that the simplest string concatenation
syntax.
What I would like as the end result, ( since Tim will want to know
the problems for which I'm hunting for a solution ) is to be able
to type "help( something )" in Python, and have Mosaic, or some other
browser, pop up and display a nicely formatted html document, or
minimally, a nroffed and formatted text help screen.
In a compiled language where you are going to be running 'make' over
the sources every once and a while, there is no problem with weaving
the text and documentation together, and unentwining them just before
compile, but an interpreted language like python can't depend on an
external program like make easily. Literate programming support has
to be somehow embedded into it in the same way that update of .pyc
code is.
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cognitive Science is where Philosophy goes when it dies ...
if it hasn't been good!" - Jerry Fodor ]