[Tutor] Puzzled again

[Richard D. Moores]

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.

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