[Python-Dev] Suggestion: new 3 release with backwards compatibility

["Martin v. Löwis"]

> No-op constructions like 'bytes("")' could help for older versions of
> Python, though.  A very, very small runtime shim could provide
> support for these, if 2to3 could be told about it somehow.

You actually don't *need* 2to3 support for that - bytes("") can work
in either version:

2.x:
def bytes(s):
  return s

3.x:
def bytes(s)
  return s.encode("ascii")

On top of that, you *could* as for bytes("") to be converted to b"" in
3.x - and it is indeed possible to tell 2to3 about that, and you don't
even need to modify 2to3's source to do so: it can be part of your
package.

>> Also, running 2to3 on installation is kind of annoying, as you get
>> source that isn't itself the canonical source, so to fix bugs you
>> have to look at the installed source and trace it back to the bug
>> in the original source.
> 
> Given the way tracebacks are built, i.e. from filenames stored in
> .pycs rather than based on where the code was actually loaded in the
> filesystem, couldn't 2to3 could do .pyc rewriting to point at the
> original source?  Sort of like our own version of the #line
> directive? :)

I think it could, but it would be fairly flaky as the pycs
can get lost, and lose that information after regeneration. Also,
it may be confusing in other scenarios.

I'd rather have it generate separate mapper files, and change the
traceback printing to consider these (as an option).

> Seriously though, I find it hard to believe that this is a big
> problem.  The 3.x source looks pretty similar to the 2.x source, and
> it's good to look at both if you're dealing with a 3.x issue.

That's my experience as well - the only challenge is that you can't
cut-n-paste the source URL into an editor.

Regards,
Martin