[Tutor] Puzzled again
Richard D. Moores
rdmoores at gmail.com
Wed Aug 3 22:20:23 CEST 2011
On Wed, Aug 3, 2011 at 12:16, Steven D'Aprano <steve at 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.
> 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
> 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.
More information about the Tutor