RFC PEP candidate: q'<delim>'quoted<delim> ?

[Jeff Shannon]

Bengt Richter wrote:

> The problem to solve is not constructing an arbitrary-valued string
> by writing an escaped sequence adhering to current python string syntax.
> That can be done, as you show.
>
> The problem is to do it by using an existing source of text, without
> changing the text, and without using an external file to delimit it.

My take on all of this is:

1)  Only when dealing with Python source code or raw binary data is it likely
that triple quotes will be found.  Raw binary data is better expressed entirely
in quoted hex or octal form, anyhow, to make it clear that it *is* binary, so
this change is really only beneficial when quoting Python code.

2)  Only when cutting and pasting large sections of Python code (small sections
are unlikely to have multiline quotes) to be used as string literals in other
Python code, does this quoting problem arise.  One can read from a file, import
another module, read from a database, etc, etc, without having much worry here;
cutting and pasting seems the only case where quotation issues come into play.

3)  The need to use arbitrary Python code as a string literal is... well...
rather abstruse.  It is not something that comes up often, and (ISTM) is
confined to relatively specialized tasks.  (I can't think of anything other than
that code generator you mentioned, and even there, I wouldn't think that
*arbitrary* code would be desirable...)

4)  Python code that uses both ''' and """ within reasonably-sized stretches of
code is pretty rare.

5)  Because of (4), most cases of cutting and pasting Python code into string
literals can be handled simply by choosing the style of triple quotes that the
source doesn't use.  To be honest, your example of quoting a segment of code
that includes a quoted segment of code seems rather artificial and contrived; I
find it hard to imagine a case where this would be desirable, and (ISTM) odds
are that any such case would likely be served as well (or better) by some other
technique (such as the aforementioned data files, etc.)

6)  In most cases where it *is* desirable to quote large sections of Python
code, you'd want to be reviewing and modifying and tidying the code *anyhow*.
During such tidying, it would not be difficult to normalize the quoted text to
use all the same type of triple quotes, or (if they're nested) change one type
to be represented as escaped hex.  (Note again, as per (4), nested triple quotes
seem to be rare.)

7)  As a result of all of this, there seem to be vanishingly few cases in which
quoting reasonably sized sections of text to use as string literals, can't be
accomplished through the use of standard triple quotes.  Only when triple quotes
are nested within the source text, or when it's impractical to see *what* you're
quoting (and why are you quoting it if you don't know what it is?), would the
standard triple quotes be insufficient.

8)  If we *had* this arbitrary-delimited quote, then many people would feel that
they should be used everywhere, even though triple quotes would often do the job
just as well (and far more clearly).  For example, note how many people want to
use eval() and exec to accomplish things that can be done far more simply,
cleanly, and safely by using a standard module.  I'm sure that the same would
happen with arbitrary delimiters.  Not only that, but I can well imagine people
choosing "clever" delimiters that, while being unique enough to be parseable,
don't stand out visibly enough to make it easily apparent where the particular
quoted string ends.  (As per your previous example, it took me over a minute to
figure out where those quotes ended;  with triple quotes, it takes me about a
second.  That's almost two orders of magnitude difference -- to me, that's
significant confusion.)

In short, I see the need for arbitrarily-delimited string literals to be a very
rare, and very specialized thing, and providing special core syntax to deal with
this rare special case is both unnecessary and likely to create lots of
opportunity for confusion.  And (ISTM) there is only one of your conditions
which makes current Python syntax unsuitable for the usage you're envisioning --
the desire to not have to actually examine what you're cutting and pasting.
(Note that, if you're doing this a lot, it shouldn't be too hard to have a smart
editor examine pasted text and create a suitable string literal that can be
normally triple-quoted.)  Python is intended to be simple and clean; this
proposal is (IMHO) neither.

Jeff Shannon
Technician/Programmer
Credit International