All in favor of keeping it simple.
> ...
> Neither do I like the idea of stripping indentation from strings --
> for consistency, this would have to check that all lines in the string
> are indented consistently,
??? Was trying for a life-preserver, not a straight-jacket <wink>.
E.g., """\
nobody wants to be forced to put 8 blanks on an empty line
between paragraphs.
"""
> and it would require adding backslash-space and backslash-tab as
> escapes interpreted in string literals.
OK, strip _all_ leading indentation from _all_ lines in a triple-quoted
string. This caters to the most common case. Then the following
argument can be applied to the exceptional cases instead:
> However, a user function could strip indentation from long string
> literals using rather simple regular expression replacement!
I.e., if all leading whitespace were stripped, then in those unusual
cases where some leading whitespace was wanted here & there, a user
function could be called to put it in:
print user_function("""\
I didn't want the whitespace here
or here, but do want one blank at the start of the next line
\Owhere '\O' means one blank; and I want 5 on the next line:
\B where '\B' means two blanks; and a tab on the next:
\Twhere '\T' means a tab.
And none here.
""")
There's nothing special about those escapes to Python, it's just this
user_function's convention. If we call a user function to strip
whitespace instead, we'll have to make up an equally arbitrary convention
(about how much to strip) for that.
The difference is in whether the rules make it easy or hard to write the
most common cases without mucking up the appearance of the program.
I'm beginning to suspect we don't agree on this one <wink>.
> ... %(name)format could be changed into %(expression)format, passing
> the expression to eval() with the given dictionary as globals.
> Disadvantage: ... it needs a way to pass zero, one or two dictionaries
> on to eval().
It seems that if %(expression)format needs this, then %(name)format does
too. I.e., they're both in the business of resolving names -- what's the
key difference between, e.g., "%(n+1)3d" and "%(n)3d"?
> The latter could be solved by being a little cleverer and allowing (),
> (globals), or (globals, locals) as right-hand-side argument to the %
> operator.
I like that idea more than the idea of allowing expressions, since I
expect I'll usually be writing
string % vars()
under the current %(name)format idea, and binding globals to locals
beforehand if 'string' references globals (so 'vars()' will pick them
up). Would make life simpler to skip all that and just write
string % ()
instead.
> [john]
> ...
> The basic goal is to keep ugly strings out of the code...
Mine too, but I'd rather get them in the code by making them appear
beautiful in the source text.
> ...
> I definitely dislike the functionality(""") != functionality(''')
> thing.
That one seemed to die an unlamented death. I.e., far as I can tell
(while admitting to some guesswork), triple-single and triple-double are
treated alike by everyone now.
> [steve]
> IF some sort of triple quoted multi-line string is going to be added,
> I would like to contradict myself (again) and AGAIN propose that an
> optional lisp-like doc-string syntax be added to the syntax for def
> ( and maybe lambda ) along with a new function attribute: func_doc,
> to hold that string.
>
> def function( args ) 'minimal one line description of function' :
> do_something
>
>
> def otherfunction( args ) """
> I haven't been following this discussion closely enough to remember
> the current proposed rules for whitespace, etc. in these multi-line
> strings but, I assume that whatever the syntax, it will solve the
> problem of multi-line documentation. \n""" :
> do_something_else
Aren't you glad I didn't vote your proxy <grin>? I like the idea, but do
picture what the typical module will _look_ like if not only your top-
level functions, but your class methods too all have doc text jammed up
against column 1. That's what the "strip leading whitespace" no-longer-
an-argument has been about. In this particular case, since you intend
to do processing on the doc string anyway, it would be valuable to define
that processing to include stripping some amount of leading whitespace
(assuming that indeed the triple-quoted string forms won't do that for
you).
> ... I'm still voting for vars() and explicit namespacing, Tim.
Me too!
guess-you-coulda-let-me-keep-your-proxy-anyway<smile>-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp