[Python-Dev] Triple-quoted strings and indentation

[Andrew Durdin]

On 7/6/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> However, while I prefer what you describe to Python's current
> behaviour, I am not yet convinced the backward compatibility pain is
> worth it. Adding yet-another-kind-of-string-literal (when we already
> have bytestrings on the horizon) is also unappealing.

First off, thanks for your feedback--you raise some very good points
that I have addressed insufficiently or not at all.

I personally feel that backward compatibility issues provide the
strongest argument against accepting the proposal (but obviously I
find the rest of it favourable :-).  It may not be particularly clear
(that's why it's a draft) that I am not proposing another kind of
string literal, but rather a change of rules for an existing one.
 
> Your readability examples are good, but the first two involve strings
> that should probably be module level constants (as Terry described)
> and the test case involving expected output is probably better handled
> using doctest, which has its own mechanism for handling indentation.

I think the question of whether an inline string should be made a
module-level constant (or moved to a separate file entirely) relates
in general to higher-level considerations of readability and program
structure (similar, for example, to those that would prompt one to
refactor a function). IOW, the answer to that question would be the
same with or without this proposal. In any case, I chose the examples
(from different parts of the standard library) more because they
illustrated different classes of usage for TQS's than because they
were the best illustrations of readability improvement--perhaps
something I should address.

> Raw and unicode string literals need to be mentioned in the PEP. Which
> literals would the reformatting apply to? All 3? Only standard and
> unicode, leaving raw strings alone?

The proposal would apply to all 4 :-) -- normal, raw, unicode, and raw unicode.

> You should research the reasons why PEP 295 [1] was rejected, and
> describe in the new PEP how it differs from PEP 295 (unfortunately PEP
> 295 was not updated with the rationale for rejection, but this post
> [2] looks like Guido putting the final nail in its coffin).

THANK YOU! In my research for this, I didn't come across PEP 295 at
all -- perhaps due to the fact that it uses the term "multiline
strings" exclusively, which is not how I would describe them at all. 
I will certainly address this in my next draft.

Cheers,

Andrew.