On 8/7/2019 6:57 PM, raymond.hettinger@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:forrestgump@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