On Dec 27, 9:49 pm, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> The fact is...even with the multi-line issue solved, we still have two
> forms of literal delimiters that encompass two characters resulting in
> *four* possible legal combinations of the exact same string! I don't
> know about you guys, but i am not a big fan of Tim Towtdi.
actually i was a bit hasty with that statment and underestimated the
actual number of possiblities.
1) "this is a string"
2) 'this is a string'
3) r"this is a string"
4) r'this is a string'
5) '''this is a string'''
6) """this is a string"""
7) r'''this is a string'''
8) r"""this is a string"""
A) "this is difficult to \"eyeball parse\""
B) """this is "overkill""""
C) "that's just plain \"nuts\"!"
Now. If anyone can look at that mess and not admit it is a disaster,
well then...
I am also thinking that ANY quote char is a bad choice for string
literal delimiters. Why? Well because it is often necessary to embed
single or double quotes into a string literal. We need to use a
delimiter that is not a current delimiter elsewhere in Python, and
also, is a very rare char. I believe Mr Ewing found that perfect char
in his "Multi-line uber raw string literals!" (Just scroll down a bit
at this link)...
http://www.cosc.canterbury.ac.nz/greg.ewing/python/ideas.html
...however, requiring a programmer to start EVERY line with a marker
does not seem like fun to me. And just think what a nightmare it will
be to modify copy/pasted data with line markers! Although it does
solve the "indention" issue with doc-strings! I think just for foreign
language compatibility reasons we should stick with one of either " or
' (or maybe both), but allowing [r]""" and [r]''' is just WAY too
much! We need to trim this fat.
--
http://mail.python.org/mailman/listinfo/python-list
