[Python-Dev] Triple-quoted strings and indentation (original) (raw)

Andrew Durdin adurdin at gmail.com
Sun Jul 10 13:21:48 CEST 2005

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.

More information about the Python-Dev mailing list