From: Lie Ryan on
On 04/29/10 16:34, Steven D'Aprano wrote:
> On Thu, 29 Apr 2010 02:16:46 +0100, MRAB wrote:
>
>> Steven D'Aprano wrote:
>>> On Thu, 29 Apr 2010 06:17:42 +1000, Lie Ryan wrote:
>>>
>>>>> Consider that the concatenation language feature probably is there
>>>>> because it's useful (e.g. it preserves indentation and allows per
>>>>> line comments).
>>>> No, the implicit concatenation is there because Python didn't always
>>>> have triple quoted string.
>>>
>>> Do you have a source for that?
>>>
>>> Both triple-quoted strings and implicit concatenation go back to at
>>> least Python 1.4:
>>>
>>> http://docs.python.org/release/1.4/tut/node71.html
>>> http://docs.python.org/release/1.4/tut/node70.html
>>>
>> The page here:
>>
>> http://svn.python.org/projects/python/branches/py3k/Misc/HISTORY
>>
>> says release 1.0.2 (4 May 1994).
>
> Yes, it says:
>
> * String literals follow Standard C rules: they may be continued
> on the next line using a backslash; adjacent literals are
> concatenated at compile time.
>
> * A new kind of string literals, surrounded by triple quotes
> (""" or '''), can be continued on the next line without a
> backslash.
>
>
> These are adjacent entries in the same release. That's pretty good
> evidence that both implicit concatenation and triple quotes were
> introduced at the same time.

Yes, apparently my statement that implicit concatenation is an artifact
is erroneous but it doesn't make the important points less true, that
implicit concatenation is not suitable for integrating large chunk of
text into source code.

And if you do care about the two extra newlines, you can add two
backslashes:

s = """\
....
insert large chunks
....\
"""

which is a constant-time preformatting compared to prepending and
appending every line with quotes, which is O(n) (and we're talking about
the oh-so-expensive programmer's time here).

Ben Finney also showed the trick to let a large chunk to appear indented
and stripping the indenting at runtime in another thread (which is
actually rarely needed since, since as I previously said, huge chunk of
text is usually global-level variable; though the trick does come handy
sometimes).
From: Carl Banks on
On Apr 28, 11:16 am, "Alf P. Steinbach" <al...(a)start.no> wrote:
> On 28.04.2010 18:54, * Lie Ryan:

> > Python have triple-quoted string when you want to include large amount
> > of text;
>
> Yes, that's been mentioned umpteen times in this thread, including the *very
> first* quoted sentence above.
>
> It's IMHO sort of needless to repeat that after quoting it, and providing yet
> another example right after quoting an example.
>
> Probably you didn't notice?


I think he repeated it just to let people know that they can get what
they want without following your adsurd advice.


Carl Banks
From: Alf P. Steinbach on
On 30.04.2010 01:29, * Carl Banks:
> On Apr 28, 11:16 am, "Alf P. Steinbach"<al...(a)start.no> wrote:
>> On 28.04.2010 18:54, * Lie Ryan:
>
>>> Python have triple-quoted string when you want to include large amount
>>> of text;
>>
>> Yes, that's been mentioned umpteen times in this thread, including the *very
>> first* quoted sentence above.
>>
>> It's IMHO sort of needless to repeat that after quoting it, and providing yet
>> another example right after quoting an example.
>>
>> Probably you didn't notice?
>
>
> I think he repeated it just to let people know that they can get what
> they want without following your adsurd advice.

Perhaps you could quote the advice that you find absurd, and explain how you
interpret the quoted text?

My previous experience with you is that you immediately called me "insane" (and
worse) for suggesting a solution that could work in principle and did work in
practice for the problem posed in that thread; I think you resorted to such
characterizations because you had stated that it was impossible.

So until you get a bit more concrete I'm interpreting your characterization
(about what?) as just confirming & uphelding the impression you made back then.


Cheers & hth.,

- Alf
From: Steven D'Aprano on
On Fri, 30 Apr 2010 05:41:26 +1000, Lie Ryan wrote:

> On 04/29/10 20:40, Gregory Ewing wrote:
>> Lie Ryan wrote:
>>> No, the implicit concatenation is there because Python didn't always
>>> have triple quoted string. Nowadays it's an artifact and triple quoted
>>> string is much preferred.
>>
>> I don't agree. I often use implicit concatenation when I'm writing a
>> format string that won't fit on one source line, because it allows me
>> to fit it into the surrounding indentation structure without
>> introducing unwanted spaces into the string.
>>
>> Both tecnhiques have their places.
>>
>>
> That statement should be quantified with "for large chunks of text".
> Format string is typically 2-3 lines at most, not enough to qualify as
> large chunk.

No it shouldn't. It applies equally for two lines or two hundred lines.

You seem to have missed that these are NOT equivalent:

"""abcd
efgh"""

"abcd"\
"efgh"


To avoid the ugly backslash, you can use Python's implicit line
continuation inside brackets. This is especially handy since you often
use brackets for function calls:

len(
"this is a very long string that won't fit"
" on a single line in the source code, but"
" must be a single line string, which is why"
" a triple-quoted string is not appropriate.")

To get the same result using triple-quoted strings, you would need to do
this:

len(
"""this is a very long string that won't fit\
on a single line in the source code, but\
must be a single line string, which is why\
a triple-quoted string is not appropriate.""")


but the second is risky, because an invisible whitespace character
following the backslash will introduce bugs into your code:

>>> assert len(
.... """abc\
.... def""") == 6
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
AssertionError




--
Steven
From: Lie Ryan on
On 04/30/10 13:21, Steven D'Aprano wrote:
> On Fri, 30 Apr 2010 05:41:26 +1000, Lie Ryan wrote:
>
>> On 04/29/10 20:40, Gregory Ewing wrote:
>>> Lie Ryan wrote:
>>>> No, the implicit concatenation is there because Python didn't always
>>>> have triple quoted string. Nowadays it's an artifact and triple quoted
>>>> string is much preferred.
>>>
>>> I don't agree. I often use implicit concatenation when I'm writing a
>>> format string that won't fit on one source line, because it allows me
>>> to fit it into the surrounding indentation structure without
>>> introducing unwanted spaces into the string.
>>>
>>> Both tecnhiques have their places.
>>>
>>>
>> That statement should be quantified with "for large chunks of text".
>> Format string is typically 2-3 lines at most, not enough to qualify as
>> large chunk.
>
> No it shouldn't. It applies equally for two lines or two hundred lines.



> You seem to have missed that these are NOT equivalent:
>
> """abcd
> efgh"""
>
> "abcd"\
> "efgh"
>
>
> To avoid the ugly backslash, you can use Python's implicit line
> continuation inside brackets. This is especially handy since you often
> use brackets for function calls:

You *again* missed the point. The purpose here is to *avoid manual
preprocessing* of the text chunk string concatenation is not suitable
for including large text. Implicit because they force you to preprocess
the chunk before python will accept the text into the source code. If
you added backslashes inside triple-quotes, it's just as ugly as
implicit continuation.

When you don't want the newline, then just let the text flow, there is
no need to *artificially* break the lines, whether using backslash or
implicit concatenation. Triple quoted string is a place where 80-char
limits (or whatever number you set) shouldn't apply; if you insist on
having string inside triple-quotes to be obey 80-chars, then it's just
foolish consistency.

With triple quoting, you just need to copy, paste, then add *exactly
two* backslashes if preserving exact newline is crucial. Compare that
with adding a quote before and after *each line*. That is O(1) vs O(n)
difference.

Large chunk of text inside source code is usually there because you're
too lazy to create a separate file for it. When you're too lazy to even
create a file, you're not likely to be that industrious to do any sort
of preprocessing to the chunk. And you most likely won't care that the
source code looks ugly if it exceeds the oh-so-sacred 80-char limit,
because scripts with that kind of nature (i.e. includes large text chunk
instead of separate file) is typically one-off throwaway scripts. You
want to start working on the chunk immediately instead of spending
ten-minutes forcing python to grok the text.