Suggestions to triple quoted strings proposal
On Dec 12, 2006, at 11:24 AM, Stepan Koltsov wrote:
First,
I suggest to ignore first character of string if it is newline. So
statementmessageTemplate = """ Hello, I've just... """
should be equivalent to
messageTemplate = "Hello,\nI've just...\n"
, but not
messageTemplate = "\nHello,\nI've just...\n".
This is not what Python does:
s = """ ... hi ... there ... """
s '\n hi\n there\n'
And second: to ignore same number of spaces as number of spaces in the line where triple quoted string started. Example:
function query() { return """ SELECT * FROM people WHERE date_created > ? AND disabled = 'N' """ }
should be equivalent to
function query() { return "SELECT * FROM people\nWHERE date_created > ? AND
disabled = 'N'\n"; }but not as now:
function query() { return " SELECT * FROM people\n WHERE date_created > ? AND disabled = 'N'\n"; }
I think that these improvements would make triple quoted string more useful and easier. Hope, these suggestions will be added to proposal.
This is a different kind of quoting than what " or """ means in JS or
Python. It seems to me to warrant a different syntax, if it's worth
doing at all. The counterargument besides "don't diverge from
Python" is: "just don't indent or add extra newlines you don't want
in the literal."
Literal means verbatim, quotes mean verbatim. Stripping leading
uniform indentation (or did you mean any leading whitespace, even if
the first line has three chars and the second has seven, etc.) is not
verbatim. Chomping leading and trailing newlines is not verbatim.
The "KISS" principle favors the minimal, What you typed is what you
get (WYTIWYG? sorry) approach.
My two cents, anyway.
Brendan Eich wrote:
On Dec 12, 2006, at 11:24 AM, Stepan Koltsov wrote:
And second: to ignore same number of spaces as number of spaces in the line where triple quoted string started. Example:
function query() { return """ SELECT * FROM people WHERE date_created > ? AND disabled = 'N' """ }
should be equivalent to
function query() { return "SELECT * FROM people\nWHERE date_created > ? AND disabled = 'N'\n"; }
but not as now:
function query() { return " SELECT * FROM people\n WHERE date_created > ? AND disabled = 'N'\n"; }
This is a different kind of quoting than what " or """ means in JS or Python. It seems to me to warrant a different syntax, if it's worth doing at all. The counterargument besides "don't diverge from Python" is: "just don't indent or add extra newlines you don't want in the literal."
A further note
I suggest to ignore first character of string if it is newline.
Can you explain why this would be useful?
If you ignore the first new line, should you also ignore all leading new lines? It's not obvious how it would behave in that situation, which makes it immediately "harder" - but that could be just because I don't understand the use-case. Also, if you actually wanted to include leading newlines you'd then have to use escape sequences which would seem to defeat the whole point of """.
Assuming that there are some really convincing use-cases, perhaps something along the lines of literal regexp options syntax could work. e.g:
query = """ SELECT * FROM people WHERE date_created > ? AND disabled = 'N' """n;
// n signifies ignore leading white on each line
But I'm dubious about how useful that is, compared to the extra complexity, and I think Brendan is right about keeping it simple (though I can't see "WYTIWYG" catching on ;-))
Btw is there a discussion somewhere, deciding on triple-quotes in preference to heredoc syntax?
Peter
Another quick comment. With the addition of E4X, you can use triple-nested multiline strings with this slightly mucky workaround:
var q:String = <>
"Som'e' "
multiline text
</>.toXMLString();
In the AS3 implementation, this is equivalent to:
var q:String = ""Som'e' "\n\t\t'mult'iline text";
Which is interesting for comparison, as it ignores all leading but not subsequent white.
Peter
Peter Hall wrote:
Which is interesting for comparison, as it ignores all leading but not subsequent white.
This is due to XML.prettyPrinting being true, I suspect; I'd check if I had more free time right now. Also, unless you drop to entities you can't embed {, }, or < in the string this way.
On Dec 12, 2006, at 2:14 PM, Jeff Walden wrote:
Peter Hall wrote:
Which is interesting for comparison, as it ignores all leading but
not subsequent white.This is due to XML.prettyPrinting being true, I suspect; I'd check
if I had more free time right now. Also, unless you drop to
entities you can't embed {, }, or < in the string this way.
Right.
BTW, this works in SpiderMonkey (in Firefox):
var q = String( <> "Som'e' " multiline text </>.toXMLString() );
alert(uneval(q));
On 12/13/06, Peter Hall <peterjoel at gmail.com> wrote:
I suggest to ignore first character of string if it is newline.
Can you explain why this would be useful?
I suppose we understand triple-quoted string (TQS) literals differently. Possibly you think about TQS as about ability to insert raw binary data into the program (WYTIWYG). I think TQS allows easily embed good old plain texts. Plain text is a sequence of lines joined by newline. "What you see is what you get" works here :) Look at the code:
=== function query() { return """ SELECT 15 FROM dual """ }
What do you see inside of triple quotes? ;-)
I see two lines of text. First line is "SELECT 15". Second line is "FROM dual". So I think function should return text consisted from these two line joined by newline-separator.
About use cases. You may wish to inline mail message template inside your program.
=== class SuperDuperLogger { // ... function mailThatDataIsLost(err, users) { for (user in users) { var msgTmpl = """ Dear @USER@,
Something bad happened: all your data is lost:
@TEXT@
S.Y., Robot.
"""
sendMessage(user.email,
msgTmpl.replace("@USER@", user.name).replace("@ERR@", text));
}
}
}
This is snippet of code is to send letter if error happened. If we have Python-like multiline strings behaviour, and don't want to postprocess message template (explicitly strip spaces; we don't), we have to write same piece of code such way:
=== class SuperDuperLogger { // ... function mailAboutSeriousError(err) { for (user in users) { var msgTmpl = """Dear @USER@,
Something bad happened: all your data lost:
@TEXT@
S.Y., robot. """ sendMessage(msgTmpl.replace("@USER@", user).replace("@ERR@", text)); } } }
It looks really bad. Text breaks loop, function and class body. We do not see the place of the beginning of message template.
My behaviour looks better in any situation where you want to get plain text. Another example: part of code generator:
function writeHead() { writer.write(""" /* * WARNING! This file is machine generated! Do not edit. * * Generated by Mega-Generator 2006 Enterprise. */ """) }
If you ignore the first new line, should you also ignore all leading new lines?
No, because line after """ is first line of text.
It's not obvious how it would behave in that situation, which makes it immediately "harder" - but that could be just because I don't understand the use-case. Also, if you actually wanted to include leading newlines you'd then have to use escape sequences which would seem to defeat the whole point of """.
Please explain better, I do not understand.
Assuming that there are some really convincing use-cases, perhaps something along the lines of literal regexp options syntax could work. e.g:
query = """ SELECT * FROM people WHERE date_created > ? AND disabled = 'N' """n;
// n signifies ignore leading white on each line
But I'm dubious about how useful that is, compared to the extra complexity, and I think Brendan is right about keeping it simple (though I can't see "WYTIWYG" catching on ;-))
Suffix "n" is unnecessary complexity. There should be either original semantics or mine.
I'd ever prohibited any text after first """ to avoid misunderstanding.
I know, that my suggestion makes rules more complex. I don't think this leads to programming errors, because described behaviour is intuitive.
-- Stepan
If you ignore the first new line, should you also ignore all leading new lines?
No, because line after """ is first line of text.
It's not obvious how it would behave in that situation, which makes it immediately "harder" - but that could be just because I don't understand the use-case. Also, if you actually wanted to include leading newlines you'd then have to use escape sequences which would seem to defeat the whole point of """.
Please explain better, I do not understand.
Assuming that
A) all (and not just the first one, as you suggest) initial newlines are ignored, and B) you want to produce a string with leading newlines using the """ syntax,
you would have to use something like """\n\n\nThe string that follows our leading newlines""".
I personally find """ (and/or ''' -- or is maybe only """ under discussion?) most unreadable -- how many quotes was that?
It's especially difficult, granted that " and ' characters look much the same in a forest of quotes, and that i e "'" is a valid one-character string. At least I can't easily tell the difference, especially when scanning code, without the aid of some Christmas tree mode (it gets even worse when discussing code in a non-monospaced environment). (If the string were to contain actual code, indented just like the surrounding code too, it gets increasingly worse.)
I would be glad either not to see the change at all, or to see some alternate syntax, perhaps the more character conservarive #"(string including literal newlines here" syntax (used by Pike).
On 12/13/06, Stepan Koltsov <stepan.koltsov at gmail.com> wrote:
Hi,
I've read proposal of triple quoted strings at
developer.mozilla.org/es4/proposals/triple_quotes.html
And I have two suggestions. I've sent them to Brendian Eich, and he redirected me to this mailing list.
I suggest to change interpretation of triple quoted string.
First,
I suggest to ignore first character of string if it is newline. So statement
messageTemplate = """ Hello, I've just... """
should be equivalent to
messageTemplate = "Hello,\nI've just...\n"
, but not
messageTemplate = "\nHello,\nI've just...\n".
And second: to ignore same number of spaces as number of spaces in the line where triple quoted string started. Example:
function query() { return """ SELECT * FROM people WHERE date_created > ? AND disabled = 'N' """ }
should be equivalent to
function query() { return "SELECT * FROM people\nWHERE date_created > ? AND disabled = 'N'\n"; }
but not as now:
function query() { return " SELECT * FROM people\n WHERE date_created > ? AND disabled = 'N'\n"; }
I think that these improvements would make triple quoted string more useful and easier. Hope, these suggestions will be added to proposal.
Eh. String should just grow a method to do that. Literals are literals and should be treated as such.
In Python you do that with the textwrap module.
textwrap.dedent("\n foo\n bar\n baz") '\nfoo\nbar\n baz'
The leading newline needs to be stripped manually (e.g. lstrip('\n')) or more commonly the opening triple quote is followed by a line continuation backslash.
Hello all, here my two cents from a user point of view
-
""", why use triple we don't even have double ? I would prefer some before-quote-parameter as in C# using @"some text here" (anyother parameter than @ is fine)
-
I like TQS because it allow to write multiline without juggling with string concatenation to keep it readable
""" hello world here another line and another line """
is much more readable in source than "hello world\nhere another line\nand another line" or somevar = "hello world\n" somevar += "here another line\n" somevar += "and another line"
so imho the goal of using """ is to be able to write readable multiline of text IN the source code
but as people indent their code
""" ....hello world ....here another line ....and another line """ (the dots being spaces)I would find usefull to have an option (even if it's not pythonesque) that strip the 4 spaces on the left automatically so if I my lines are aligned they stay readable (maybe I'm not super clear here)
my ideal notation would be something like this
@-4" ....hello world ....here another line ....and another line "@ -> we are in multiline -4 strip four spaces on the left (+4 or 4 could be used to add four spaces on the left)
resulting in this "hello world\nhere another line\nand another line"
-
one last option I would like to see also is to be able to define the line separator sequence "\n" could be the default but being able to define "\r", "\r\n" could be helpfull too
OR
Keep the TQS as simple as possible, no special string rules to remember, all is verbatim
but add a "prettyPrinting" method to the String class in order to strip spaces/whitespaces at the start of lines AND replacing the line separator at end of lines
as the String class is final, to have such method native would be inho more efficient
zwetan
On 12/13/06, zwetan <zwetan at gmail.com> wrote:
Hello all, here my two cents from a user point of view
""", why use triple we don't even have double ? I would prefer some before-quote-parameter as in C# using @"some text here" (anyother parameter than @ is fine)
I like TQS because it allow to write multiline without juggling with string concatenation to keep it readable
"""
Double quotes would probably be syntactically ambiguous. They look exactly like an empty string token...
Even if you wormed around that, one of the most common use cases for triple quoted strings (in Python) is to facilitate documentation and doctests. Triple quotes can represent any syntactically valid code without using escapes (except of course, another set of triple quotes). If it were double quotes, empty string literals would have to be escaped (or '' would have to be used).
Decorating the quote with some sigil doesn't make multi-line easier, nor does it get you around the escaping problem. Totally different use case with no feature overlap.
On 12/13/06, Bob Ippolito <bob at redivi.com> wrote:
Double quotes would probably be syntactically ambiguous. They look exactly like an empty string token...
Even if you wormed around that, one of the most common use cases for triple quoted strings (in Python) is to facilitate documentation and doctests. Triple quotes can represent any syntactically valid code without using escapes (except of course, another set of triple quotes). If it were double quotes, empty string literals would have to be escaped (or '' would have to be used).
Decorating the quote with some sigil doesn't make multi-line easier, nor does it get you around the escaping problem. Totally different use case with no feature overlap.
my concern is to have the multiline readable in the source code, if I don't need it readable I don't really need multiline and TQS, I just use a String, so now maybe the problem is the different point of view about what is "easier"
I'm personally not interested in carrying the documentation of code inside the code itself and I can bet a lot do not pursue this, so I don't think the most common use case for TQS in ES4 gonna be the same as in Python
but still TQS to define big chunk of readable text into the code can be very usefull, even if not totally Python identical (and I do like how Python do things, not bashing here).
zwetan
=== function query() { return """ SELECT 15 FROM dual """ }
What do you see inside of triple quotes? ;-)
I see two lines of text. First line is "SELECT 15". Second line is "FROM dual". So I think function should return text consisted from these two line joined by newline-separator.
It doesn't seem particularly arduous to do:
function query() { return """SELECT 15 FROM dual """ }
Peter
It doesn't seem particularly arduous to do:
function query() { return """SELECT 15 FROM dual """ }
I haven't been following this thread closely, but the above will not parse; you aren't allowed to move the argument to a return to the next line. The parser will parse that as a return with no arguments.
Whose silly idea was automatic semi-colon insertion anyway! ;-)
Peter
On 2006-12-13, at 10:13 EST, Dave Herman wrote:
It doesn't seem particularly arduous to do: function query() { return """SELECT 15 FROM dual """ }
I haven't been following this thread closely, but the above will
not parse; you aren't allowed to move the argument to a return to
the next line. The parser will parse that as a return with no
arguments.
One of the biggest traps of implicit ;s. Bitten me too many
times! But you could say:
function query() { return ( """SELECT 15 FROM dual """) }
Since I'm here, I'll just toss out the Dylan way, which is to have
adjacent strings concatenate:
function query() { return ( "SELECT 15" " FROM dual" ) }
On 12/14/06, P T Withington <ptw at pobox.com> wrote:
On 2006-12-13, at 10:13 EST, Dave Herman wrote:
It doesn't seem particularly arduous to do: function query() { return """SELECT 15 FROM dual """ }
I haven't been following this thread closely, but the above will not parse; you aren't allowed to move the argument to a return to the next line. The parser will parse that as a return with no arguments.
One of the biggest traps of implicit
;s. Bitten me too many times! But you could say:function query() { return ( """SELECT 15 FROM dual """) }
Since I'm here, I'll just toss out the Dylan way, which is to have adjacent strings concatenate:
function query() { return ( "SELECT 15" " FROM dual" ) }
In many cases you probably want to preserve the newlines though, where adjacent string concatenation makes it look like this:
return ( "while True:\n" " pass\n" );
On Dec 13, 2006, at 2:35 AM, zwetan wrote:
OR
Keep the TQS as simple as possible, no special string rules to remember, all is verbatim
Sold! ;-)
but add a "prettyPrinting" method to the String class in order to strip spaces/whitespaces at the start of lines AND replacing the line separator at end of lines
as the String class is final, to have such method native would be inho more efficient
Please comment on developer.mozilla.org/es4/proposals
string.html -- it is a late breaking and small "leaf" proposal (just
standard library we don't want everyone to have to re-implement and
deploy ad nauseum), and it is not done yet.
Brendan, or anybody else who wants multiline strings should to behave like in Python,
Could you please write complex-enough example of code with TQS? In that example string constant should be declared inside method inside class. There is no good example at developer.mozilla.org/es4/proposals/triple_quotes.html .
I used to write in Python, I hated its """ behaviour. I asked people who use Python, and they generally agreed with me.
I'm afraid, that if you keep TQS "simple", they won't be very usable: in 99% cases users will be forced to manually strip spaces and leading newline. In 1% cases string constant will be defined outside block, or amount of spaces will not matter.
I have no other arguments :)
-- Stepan
On Dec 13, 2006, at 10:59 AM, Stepan Koltsov wrote:
Brendan, or anybody else who wants multiline strings should to behave like in Python,
Could you please write complex-enough example of code with TQS? In that example string constant should be declared inside method inside class. There is no good example at developer.mozilla.org/es4/proposals/triple_quotes.html .
You're right there's no good example, but the Python docs have
examples, and real code has even more compelling examples. Two
arguments here:
-
"Be like Python, reuse brainprint from JS hackers who know Python
and Python hackers learning JS". This is non-trivial. It's not just
"marketing". It makes the world better to avoid defining """
differently in ES4/JS2 from Python. -
"Be like Python, stand on its shoulders and reuse the experience
that informed its design decisions and defaults". This is certainly
a gamble, since JS is not Python, and Python ain't perfect (JS is far
from perfect). But with some care (e.g., eliminating GeneratorExit
in the JS Pythonic generators available now in Firefox 2, and going
into ES4), it can pay off. There's probably value here, unless
Python has failed to heed negative feedback on non-stripping """. -
Quote means verbatim contents modulo escapes and special case for
embedded newlines, i.e. literal. Trimming or stripping does not fit
under the notion of "literal". Bob and I have made this point, it's
about intuition more than optimizing for the common case.
I used to write in Python, I hated its """ behaviour. I asked people who use Python, and they generally agreed with me.
Were they writing doc strings or data? We have http://
developer.mozilla.org/es4/proposals/documentation.html for
documentation, that is, Java doc-comments with simpler embedded
"markup" syntax.
I'm afraid, that if you keep TQS "simple", they won't be very usable: in 99% cases users will be forced to manually strip spaces and leading newline. In 1% cases string constant will be defined outside block, or amount of spaces will not matter.
I have no other arguments :)
This is the crux of the matter. My counter-argument is number 2,
above. If your Python experience were more common, something would
have been done. But I could be wrong.
Can you say more about what these """ strings contained in Python
(doc vs. data, etc.). More context, real examples?
On Dec 13, 2006, at 1:15 PM, Brendan Eich wrote:
On Dec 13, 2006, at 10:59 AM, Stepan Koltsov wrote:
Brendan, or anybody else who wants multiline strings should to behave like in Python,
Could you please write complex-enough example of code with TQS? In that example string constant should be declared inside method inside class. There is no good example at developer.mozilla.org/es4/proposals/triple_quotes.html .
You're right there's no good example, but the Python docs have
examples, and real code has even more compelling examples. Two
arguments here:
Of course, I revised the list to make three:
"Be like Python, reuse brainprint from JS hackers who know
Python and Python hackers learning JS". This is non-trivial. It's
not just "marketing". It makes the world better to avoid defining
""" differently in ES4/JS2 from Python."Be like Python, stand on its shoulders and reuse the
experience that informed its design decisions and defaults". This
is certainly a gamble, since JS is not Python, and Python ain't
perfect (JS is far from perfect). But with some care (e.g.,
eliminating GeneratorExit in the JS Pythonic generators available
now in Firefox 2, and going into ES4), it can pay off. There's
probably value here, unless Python has failed to heed negative
feedback on non-stripping """.Quote means verbatim contents modulo escapes and special case
for embedded newlines, i.e. literal. Trimming or stripping does
not fit under the notion of "literal". Bob and I have made this
point, it's about intuition more than optimizing for the common case.
But this is not meant to puff up the case for Pythonic """ -- point 3
is pretty strong by itself. Anyway, as you say the crucial question
is: what's the most common use-case?
On 12/13/06, Bob Ippolito <bob at redivi.com> wrote:
On 12/13/06, Stepan Koltsov <stepan.koltsov at gmail.com> wrote:
I've read proposal of triple quoted strings at ...
And I have two suggestions. ... Eh. String should just grow a method to do that. Literals are literals and should be treated as such.
We can call them "heredocs". It is term from bash man page.
I've found two operators: "<<" and "<<-" in bash man page. "<<" ignores first newline. "<<-" also (surprise!) strips "all leading tab characters from input lines and the line containing delimiter" (from bash javadoc). From that man page:
=== This allows here-documents within shell scripts to be indented in a natural fashion.
Wow! This is what I want for ES4.
Example of bash script:
=== #!/bin/bash -e
if true; then cat <<- FEOF line 1 line 2 FEOF fi
cat << EOF line 3 line 4 EOF
It prints:
=== line 1 line 2 line 3 line 4
I'm going to dig Python libraries to find the "most common use-case".
-- Stepan
On 12/14/06, Stepan Koltsov <stepan.koltsov at gmail.com> wrote:
On 12/13/06, Bob Ippolito <bob at redivi.com> wrote:
On 12/13/06, Stepan Koltsov <stepan.koltsov at gmail.com> wrote:
I've read proposal of triple quoted strings at ...
And I have two suggestions. ... Eh. String should just grow a method to do that. Literals are literals and should be treated as such.
We can call them "heredocs". It is term from bash man page.
I've found two operators: "<<" and "<<-" in bash man page. "<<" ignores first newline. "<<-" also (surprise!) strips "all leading tab characters from input lines and the line containing delimiter" (from bash javadoc). From that man page:
=== This allows here-documents within shell scripts to be indented in a natural fashion.
Wow! This is what I want for ES4.
Example of bash script:
=== #!/bin/bash -e
if true; then cat <<- FEOF line 1 line 2 FEOF fi
cat << EOF line 3 line 4 EOF
It prints:
=== line 1 line 2 line 3 line 4
I'm going to dig Python libraries to find the "most common use-case".
The most common use case in Python is definitely documentation and doctests, in which case it doesn't really matter how the indentation works because it's getting processed by some module before the user looks at it anyway. With those use cases, there's plenty of opportunity and little hassle to appropriately mangle the string.
pydoc and doctest would benefit from automatic detabbing, but they would save exactly one expression each. The downside is huge though; automatic detabbing would mean that the detabbing stuff would need to happen in C (the compiler can't use textwrap because it might not exist in compiled form!), which would be a LOT more than one expression, duplicated code (compiler in C, textwrap in Python) and would become an unnecessary maintenance burden.
again.
I've looked in sources of Python itself (checked out from svn.python.org/projects/python/trunk). Possibly, nobody writes in Python "better" then Python developers.
I've written script that counts usages of multiline strings in python source.
(Script is actually a Java program. I code in Java 10 hours a day, I do it really fast :)
Of course, most TQS in Python are used as docstrings (and doctests). There are 8214 multiline strings in Python sources.
First, I though about first newline after TQS.
There are 907 uses of multiline strings (that are not docstrings) in Python sources. Only 1/9 of multiline strings store data.
In 368 cases among 907, starting triple quotes followed by backslash and newline.
=== real example from Doc/lib/minidom-example.py
document = """
<slideshow>
...
"""
It is more then 1/3.
In 342 cases among 907, starting triple quote followed by newline.
I have no numbers that show that leading spaces should be stripped by lexer. I don't know what to measure. I can show the extraction from sources:
mx1.ru/~yozh/js2/nds-indent.txt
This file contains real-world examples of data stored inside multiline strings, where statements declared inside some blocks. I can repeat, code looks dirty.
Also I have file
Contains all fragments with TQS that are not docstrings.
Script sources can be found at
(you can look inside, if you think that my script produced wrong files)
On 12/14/06, Brendan Eich <brendan at mozilla.org> wrote:
On Dec 13, 2006, at 10:59 AM, Stepan Koltsov wrote:
Brendan, or anybody else who wants multiline strings should to behave like in Python,
Could you please write complex-enough example of code with TQS? In that example string constant should be declared inside method inside class. There is no good example at developer.mozilla.org/es4/proposals/triple_quotes.html .
You're right there's no good example, but the Python docs have examples,
BTW, Python docs has no good examples of multiline strings.
Language reference has no example. Python tutorial has something... ehh... not nice:
print """ Usage: thingy [OPTIONS] -h Display this usage message -H hostname Hostname to connect to """
this prints text surrounded by empty lines (first -- because of leading newline, last -- because print stmt adds own newline).
and real code has even more compelling examples. Two arguments here:
"Be like Python, reuse brainprint from JS hackers who know Python and Python hackers learning JS". This is non-trivial. It's not just "marketing". It makes the world better to avoid defining """ differently in ES4/JS2 from Python.
"Be like Python, stand on its shoulders and reuse the experience that informed its design decisions and defaults". This is certainly a gamble, since JS is not Python, and Python ain't perfect (JS is far from perfect). But with some care (e.g., eliminating GeneratorExit in the JS Pythonic generators available now in Firefox 2, and going into ES4), it can pay off. There's probably value here, unless Python has failed to heed negative feedback on non-stripping """.
BTW, there were no design decisions when Guido developed first version of Pyton 15 years ago as a "hobby" programming project (quote from Wikipedia).
Long time ago I asked Python developers about their interpretation of multiline strings. And they answered that behaviour is proper, and even if it was not proper, it is too late to change it.
- Quote means verbatim contents modulo escapes and special case for embedded newlines, i.e. literal. Trimming or stripping does not fit under the notion of "literal". Bob and I have made this point, it's about intuition more than optimizing for the common case.
I used to write in Python, I hated its """ behaviour. I asked people who use Python, and they generally agreed with me.
Were they writing doc strings or data? We have http:// developer.mozilla.org/es4/proposals/documentation.html for documentation, that is, Java doc-comments with simpler embedded "markup" syntax.
I asked about data. I think, documentation format is not very important.
Personally, I prefer javadoc/doxygen style over docstrings.
I'm afraid, that if you keep TQS "simple", they won't be very usable: in 99% cases users will be forced to manually strip spaces and leading newline. In 1% cases string constant will be defined outside block, or amount of spaces will not matter.
I have no other arguments :)
This is the crux of the matter. My counter-argument is number 2, above. If your Python experience were more common, something would have been done. But I could be wrong.
Can you say more about what these """ strings contained in Python (doc vs. data, etc.). More context, real examples?
Any questions?
-- Stepan
I've read proposal of triple quoted strings at
developer.mozilla.org/es4/proposals/triple_quotes.html
And I have two suggestions. I've sent them to Brendian Eich, and he redirected me to this mailing list.
I suggest to change interpretation of triple quoted string.
First,
I suggest to ignore first character of string if it is newline. So statement
messageTemplate = """ Hello, I've just... """
should be equivalent to
messageTemplate = "Hello,\nI've just...\n"
, but not
messageTemplate = "\nHello,\nI've just...\n".
And second: to ignore same number of spaces as number of spaces in the line where triple quoted string started. Example:
function query() { return """ SELECT * FROM people WHERE date_created > ? AND disabled = 'N' """ }
should be equivalent to
function query() { return "SELECT * FROM people\nWHERE date_created > ? AND disabled = 'N'\n"; }
but not as now:
function query() { return " SELECT * FROM people\n WHERE date_created > ? AND
disabled = 'N'\n"; }
I think that these improvements would make triple quoted string more useful and easier. Hope, these suggestions will be added to proposal.
-- Stepan Koltsov
Hi, I've read proposal of triple quoted strings at http://developer.mozilla.org/es4/proposals/triple_quotes.html And I have two suggestions. I've sent them to Brendian Eich, and he redirected me to this mailing list. I suggest to change interpretation of triple quoted string. First, I suggest to ignore first character of string if it is newline. So statement messageTemplate = """ Hello, I've just... """ should be equivalent to messageTemplate = "Hello,\nI've just...\n" , but not messageTemplate = "\nHello,\nI've just...\n". And second: to ignore same number of spaces as number of spaces in the line where triple quoted string started. Example: function query() { return """ SELECT * FROM people WHERE date_created > ? AND disabled = 'N' """ } should be equivalent to function query() { return "SELECT * FROM people\nWHERE date_created > ? AND disabled = 'N'\n"; } but not as now: function query() { return " SELECT * FROM people\n WHERE date_created > ? AND disabled = 'N'\n"; } I think that these improvements would make triple quoted string more useful and easier. Hope, these suggestions will be added to proposal. -- Stepan Koltsov