A source-transforming module loader for Python
gregoryszorc.com
gregoryszorc.com
It's certainly a clever hack, I just think you're more likely to introduce "subtle bugs" when you are doing something decidedly non-standard implicitly.
While explicit is better than implicit the practicality still beats purity.
EDIT: yup, only happens on Py3: https://www.mercurial-scm.org/repo/hg/rev/1c22400db72d#l2.10
Since this transformation only has any effect on Python 3, it doesn't matter if you apply it in both 2 and 3.
Even if you are 100% sure that semantically `b""` and `""` in 2.7 (let's forget about <2.7 for a moment) don't differ, you cannot be sure that the transformation itself - i.e., editing the source files - won't break something. You have two ways of doing this: either manually, where you risk human error, or by writing a tool, where you risk missing certain cases. In both cases, your perfectly good Py2 code base breaks for no good reason. Moreover, even if you create a tool for applying the transformation (actually, it looks like even this loader could be used for this) to the source, once you run it and commit (imagine the commit diff and its review process!), you can't run it again if you discover your tool missed something (so iterating and improving the tool becomes harder).
With the solution described in the article, you have 100% guarantee that nothing breaks on Py2 and simultaneously you can work on improving the tool. Once they're satisfied with the tool performance and the Py3 porting is more advanced, they can use it to convert the source files. IMHO that's a really sane strategy here.
It's also worth noting that the end goal may also not align with valid intermediate goals. I often found myself fretting about where to pivot to using a byte literal prefix, where to accept an unprefixed literal (to get pre-3.5 % formatting since the codebase used that in some places) and where I explicitly needed a unicode literal prefix (and dealing with the headache of what to do if we cared about 3.2 - the brief wasn't specific enough at first).
Just $0.02, I think everyone's experience, expectations and desire for purity will be different for porting efforts. It's worth noting that my porting work was supported by a large number of anally retentive unit and regression tests which made the effort much more frustrating but a heck of a lot more obvious when we messed it up!
i.e. you run this tool on the codebase, cache somewhere the post-tokenized-and-rewritten output, then run a separate tool that does the '' -> b'' change in the source code, rerun the tokenizer without the translation and verify the two outputs are identical?
This way one would not need to do this at runtime every time, and you would have a guarantee that your source code text changes are correct (because you compare the tokenized output between the '' and the b'' versions of the code).