On Wed, Aug 3, 2011 at 12:16, Steven D'Aprano <st...@pearwood.info> wrote: > Richard D. Moores wrote: >> >> I wrote before that I had pasted the function (convertPath()) from my >> initial post into mycalc.py because I had accidentally deleted it from >> mycalc.py. And that there was no problem importing it from mycalc. >> Well, I was mistaken (for a reason too tedious to go into). There WAS >> a problem, the same one as before. > > Richard, too much information! Please try to be more concise in your posts. > Try to find the *simplest* code that demonstrates the problem.
Yes. Sorry. > E.g. instead of a 14 line function (including docstring) you should be able > to demonstrate the problem with a TWO liner: > > def func(): > """ text r'aaa\Userswxyzabcd' """ > > In Python 3, you will get a SyntaxError complaining about a truncated > \UXXXXXXXX escape. This comes back to what I said earlier: r' inside another > string does not start a raw string. (In much the same way that [ inside a > string does not create a list.) \U instroduces a Unicode escape. Since > docstrings are unicode in Python 3, and serswxyz are not valid hex digits, > you get an error. > > To fix, you need to either make the whole docstring a raw string: > > r""" text r'aaa\Userswxyzabcd' """ Yes! That works! I didn't understand that suggestion before, partly because I had the """ on a separate line, and was also confused by the "yadda"s. > or you need to escape the backslashes: > > """ text r'aaa\\Userswxyzabcd' """ Well, that's not so good, because it distorts the example I'm giving. Right? (Hey, I learned to put examples in my docstrings from you.) > You don't even need to use import to work with this. You can just copy and > paste the string into an interactive interpreter: > > # Python 2: >>>> s = """ text r'aaa\Userswxyzabcd' """ >>>> print s > text r'aaa\Userswxyzabcd' > > > # Python 3: >>>> s = """ text r'aaa\Userswxyzabcd' """ > File "<stdin>", line 1 > SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in > position 11-13: truncated \UXXXXXXXX escape > > Remember: function docstrings are just ordinary strings. All the rules for > strings apply equally to docstrings. > > > You also report (in tedious detail!) apparent discrepancies between the > offsets reported by Python when importing the file, and the actual content > of the file at those offsets. I'm not even going to attempt to diagnose > that. Without access to the exact source files, not copy and pasted into an > email or a pastebin, there is no hope of diagnosing it. It would just be a > major waste of time and energy. > > The most likely cause is that the version of the file you are importing is > not the same as the version of the file you have open in the hex editor. No, I made sure that the 2 were the same. HxD has a refresh function, which I made sure to use (press F5). > E.g. suppose you open the file in the hex editor. Then you edit the file in > your text editor, and save changes. Then you import it in Python, which > reports the offsets according to the version of the file on disk. You look > at the hex editor, but you're seeing the *old* version, before the changes. > > Unless the problem is *reproducible*, i.e. you can repeat it at will, > there's no way of knowing for sure what happened. (Unless you have a time > machine and can go back in time to see exactly you did.) > > Don't lose any sleep over this sort of thing. We've all done it. My > favourite is when I'm making incremental edits to a file, but forget to > reload() changes in the interactive interpreter correctly. Python ends up > finding an error on (let's say) line 42, but by the time the error is > reported, line 42 on disk has changed and so the traceback prints a > completely irrelevant line. > > If you *can* reproduce the error at will, e.g. do this: > > (1) Take a source file in a known state; > (2) Import the file into a *freshly started* Python interpreter; I was always importing into a "freshly started" Python interpreter. > (3) Python reports an error on some line; > (4) but the line doesn't seem to have anything to do with that error > > and repeat it as often as you like, then it would be worth sharing the file > for further investigation, by attaching it to an email, not copying and > pasting the text from it. OK. I didn't know attachments were permitted on Tutor. But in looking at my Tutor archive in Gmail, I see that they are. Thanks. > Disclaimer: due to the way Python's parser works, sometimes a missing > parenthesis or bracket will cause a syntax error on the line *following* the > erroneous line. This is a known limitation. Happens often to me, because I tend to leave out a ')' or 2 at the end of a print() statement. Thanks for all your kind instruction and advice, Steven. Dick _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
