[PATCH 02 of 10] localrepo: bytes for errors

[Gregory Szorc]

On Fri, May 13, 2016 at 9:30 AM, Gregory Szorc <gregory.szorc at gmail.com>
wrote:

> On Fri, May 13, 2016 at 7:18 AM, Jun Wu <quark at fb.com> wrote:
>
>> On 05/13/2016 04:48 AM, Gregory Szorc wrote:
>>
>>> In theory, we might be able to implement a custom module loader on
>>> Python 3
>>> that does source/ast translation when loading .py files. But this scares
>>> me
>>> for several reasons.
>>>
>>
>> I realized the "module loader" may include the "# coding: " hack.
>> Could you explain the reasons?
>>
>
> I didn't realize the "# coding" hack is an option. That's very attractive!
>
> I suggested the module loading hack because we already have a custom
> module loader handling mercurial.* modules. We could likely extend it
> rather easily to do rewriting. But I think I like the "# coding" idea
> better. Feels simpler.
>

Playing around with a custom codec, I'm not convinced this is easier than
hacking up module import.

When you use a custom "# coding" line, the source file's bytes get passed
to the codec's decode(). To convert string literals to bytes would require
us to identify string literals and rewrite the source bytes to contain the
"b" prefix. At the point you're parsing string literals, you've just
reinvented Python's parser. So it feels to me that the proper layer to
inject the automagical rewriting would be in the parser or ast level and
that would require custom module loading.

Fortunately, Python 3.5 has all the module import bits implemented in
Python (as opposed to C), so we /should/ have the control we need to inject
ourselves into module loading at the right layer.


>
>
>>
>> I guess the reason we don't want massive codemod is because we want to
>> maintain blame information. If that's the concern, the blame-skip-revset
>> idea may be another possible solution.
>>
>
> I like when Mercurial development realizes the need for a new Mercurial
> feature :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160515/a932fb5d/attachment.html>