[Python-ideas] Alternate quote delimiters

[Ron Adam]

Chris Rebert wrote:
> On 5/11/07, Ron Adam <rrr at ronadam.com> wrote:
>>
>> While watching the various issues about raw strings and quotes being
>> discussed, I decided look into other ways to resolve string delimiter
>> collisions that might also improve pythons string handling in general.
>>
>> And I'd figure I'd let it get shot full of holes here first. ;-)
> 
> Here come the first shots. ;-)

Great!  ;-)


>> So how about a multiple quoting solution?  The examples of this in the 
>> wiki
>> page are of the form...
>>
>>     qq^I said, "Can you hear me?"^
>>
>>     qq at I said, "Can you hear me?"@
>>
>>     qq§I said, "Can you hear me?"§
>>
>>
>> But that doesn't fit well with pythons use of quotes.  But a variation of
>> this would.  Add a 'q' string prefix similar to the 'u' and 'r' prefix's
>> that takes the first character inside the quotes as an additional
>> delimiter.  Then ending quote will then need to have that same character
>> proceeding it.
>>
>>     q"^I said, "Can you hear me?"^"
>>
>>     q"""|I said, "Can you hear me?"|"""
>>
>> The vertical bar is part of the quote here, not part of the string.
> 
> Ick. This will make python code harder to parse (I wonder whether the
> current parser even do what you propose), and isn't that much of an
> improvement in ease of expression.

The tokanizer can be modified to convert any of these to standard or raw
strings accordingly.  It just needs to find the beginning and the end. I
haven't looked into what will be needed to pass the delimiter to the
compiler yet.  So in it's simplest form, it's just a bit of preprocessing.


> Also, this seems way too perlish
> for my tastes. There should be only one way to do quoting, but
> practicality beat purity for quotes and regexes. However, allowing
> arbitrary quoting characters seems like overkill.

Then limit it to just a smaller set of characters.  Which ones do you suggest.

Perl uses the forms above I didn't choose.  Those don't even look like
strings to me, which is why id didn't even consider them.  Almost every
other solution has problems of some sort.  This is the only solution I
liked that did not have any problems.  Like anything new it may take a
little getting used to before it seems like python rather than something
tacked on.


>> Because the beginning and ending of the strings are not identical, it's
>> possible that they can allow nesting.
>>
>>      rq"""^
>>          rq"""^
>>                    This is a nested string.
>>          ^"""
>>          """
>>                    Another nested string.
>>          """
>>      ^"""
>>
>>
>> The most useful feature of this would be in temporarily commenting out
>> large blocks of python code.  Currently this doesn't work well if the 
>> block
>> that contain triple quoted doc strings.
> 
> A block commenting syntax may be useful, however I don't like this
> proposal because of the previous point. Also, most python editors let
> you block comment out stuff with a command to add the appropriate #s
> pretty easily.

True, and that is what I do.  However, most non-python editors need macros
programed into them if they have them, if they don't,  you must fall back
to manually adding #'s to each line.


>> Another option might be to designate certain quote delimiters for special
>> purposes.
>>
>>      Dedented strings.
>>
>>      q"""<
>>          This is a
>>          Dedented
>>          Paragraph.
>>      <"""
>>
>>
>>      Commented out source code.
>>
>>      q"""#
>>      def foo(bar):
>>          """
>>             A bar checker.
>>          """
>>          return bar is True
>>      #"""
> 
> I'm neutral on these.

The choices of delimiters in these cases need not be carved in stone.  It
can be an informal standard as well.


>>      ReST formatted strings.
>>
>>      rq""":
>>          Bullet lists:
>>
>>          - This is item 1
>>          - This is item 2
>>
>>          - Bullets are "-", "*" or "+".
>>            Continuing text must be aligned
>>            after the bullet and whitespace.
>>
>>          Note that a blank line is required
>>          before the first item and after the
>>          last, but is optional between items.
>>      :"""
> 
> Seems like a little much to have syntax for ReST. Is it used
> frequently enough to justify adding this?

It's not really syntax for reST in this case.  It's more of a very general
method to notate or tag a string.  There may be other uses for that as well.


> - Chris Rebert

Cheers,
    Ron