On 8/7/2019 6:57 PM, raymond.hettin...@gmail.com wrote:
For me, these warnings are continuing to arise almost daily. See two recent
examples below.
Both examples are fragile, as explained below. They make me more in
favor of no longer guessing what \ means in the default mode.
The transition is a different matter. I wonder if future imports could
be (or have been) used.
In both cases, the code previously had always worked without complaint.
Because they are the are in the subset of examples of the type that work
without adding an r prefix. Others in the class require an r prefix.
Ascii art:
''' How old-style formatting works with positional placeholders
print('The answer is %d today, but was %d yesterday' % (new, old))
\--------------------o
\------------------------------------o
'''
In general, ascii art needs an r prefix. Even if one example gets away
without, an edited version or a new example may not. In the example
above, the o looks weird. Suppose '\' were used instead. Suppose one
pointed to parentheses instead and ended up with this teaching example.
'''Sample code with parentheses:
print('The answer is %d today, but was %d yesterday' % (new, old))
\-------\
\----------------------------------------------------------\
These parentheses are properly nested.
'''
Whoops. This is what I mean by fragile.
A new example:
alpha_slide = '''
-----
\abcd
*\bcd
**\cd
***\d
****\
-----
'''
print(alpha_slide)
# This looks nice in source, but the result is
-----
bcd
*cd
**\cd
***\d
****-----
where the appearance of \a and \b depends on the output device.
Ascii art never needs cooking. I would teach "Always prefix ascii art
with r" in preference to "Don't bother prefixing ascii art with r unless
you really have to because you use one of a memorized the list of
escapes, and promise yourself to recheck and add it if needed everytime
you edit and are able to keep that promise".
vCard data item:
# Cut and pasted from:
# https://en.wikipedia.org/wiki/VCard#vCard_2.1
vcard = '''
BEGIN:VCARD
VERSION:2.1
N:Gump;Forrest;;Mr.
FN:Forrest Gump
ORG:Bubba Gump Shrimp Co.
TITLE:Shrimp Man
PHOTO;GIF:http://www.example.com/dir_photos/my_photo.gif
TEL;WORK;VOICE:(111) 555-1212
TEL;HOME;VOICE:(404) 555-1212
ADR;WORK;PREF:;;100 Waters Edge;Baytown;LA;30314;United States of America
LABEL;WORK;PREF;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:100 Waters Edge=0D=
=0ABaytown\, LA 30314=0D=0AUnited States of America
ADR;HOME:;;42 Plantation St.;Baytown;LA;30314;United States of America
LABEL;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:42 Plantation St.=0D=0A=
Baytown, LA 30314=0D=0AUnited States of America
EMAIL:forrestg...@example.com
REV:20080424T195243Z
END:VCARD
'''
Thank you for including the link so I could learn more. In general,
vCard representations should be raw. The above uses the vCard 2.1 spec.
The more commonly used 3.0 and 4.0 specs replace "=0D=0A=" in the 2.1
spec with a raw "\n". If the above were updated, it might appear to
'work', but would, I believe, fail if fed to a vCard processor. This is
what I mean by 'fragile'.
I would rather teach beginners the easily remembered "Always prefix
vCard representations with 'r'" rather than "Only prefix vCard
representations with 'r' if you use the more common newer specs and use
'\n', as you often would." (I don't know if raw '\t' is ever used; if
so, add that.)
The above is based on the idea that while bytes and strings are
'sequences of characters (codes)', they are usually used to represent
instances of often undeclared types of data. If the strings of a data
type never need cooking, and may contain backslashes that could be
cooked but must not be, the easiest rule is to always prefix with 'r'.
(Those with experience can refine it if they wish.) If instances
contain some backslashes that must be cooked, omit 'r' and double any
backslashes that must be left alone.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/TOV634XSDSM57ZZYGDOMBFNUT6VVI3P7/
