On 7/6/05, Nick Coghlan <[EMAIL PROTECTED]> 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com