[I got failed issue tracker submission, trying again...]

>> How about this phrasing: “Make 2to3 fixers not touch code in a
>> block starting with ’if sys.version >= '3'’“
>> (and hexversion, version_info, you get the idea)?

Right, almost... it doesn't need to be flexible, it only needs to be
documented for 2to3.  So it also doesn't need to handle the varions
version variables - if e.g. version_info is easiest for 2to3, it need
only handle that.  I've been posting with routine avoidance of testing
versions instead of features (learned from javascript frustration:-)
but that concern was misplaced here.

But it should be "if sys.version {either < or >=} '3':", and it should
not touch the else: block either.  Just trust that the programmer has
written correct version's code for each block, and parse one of the
blocks to pick up whatever info 2to3 needs to process the rest of the
python file.

So...

> I don't think this can work. You may have to write code like
> 
> if sys.version_info >= (3,):
>   try:
>     some_code()
>   except Exception, e:
>     pass
> 
> (i.e. not use the "as" syntax), because it otherwise won't parse on
> Python 2. Hence, one has to rely on 2to3 fixing it, even though
> it will never be run on Python 2.

I assume it should be "if sys.version_info < (3,):" since that looks
like Python 2 code, and that'll work with the above revised suggestion.

> So any scheme of skipping code must be opt-in.

Fair enough, if it's a 2to3 option which to obey whatever "skip some
code" hack is defined.  That's the same 2to3 command line for a lot of
files, instead of different commmand lines for different files.

Unless we're still talking past each other - if the example code will
never run on Python 2 as you say, there's no reason not to fix syntax
problems like the above.  It's fixing things like bytes vs str which
takes more thought.

> While I now understand what is being requested, I still fail to see
> the rationale. In my applications of 2to3, I never look at the generated
> code, so it doesn't bother me at all if print gets another pairs of
> brackets, or if redundant (but dead) import statements are inserted.

Wow.  We live in different mental worlds.  It would not have occurred
to me to take the 2to3 output as more than helpful suggestions.  Some
to be applied straight (like 'except' syntax), other to maybe apply
but also look closer at nearby code.

Indeed, one of my early 2to3 experiences led to a bug in python 3 code
which I'm now discussing in comp.lang.python.  Also my internal bug
detector zooms in on ((foo)) when I read Python code - I'm seeing code
where something was apparently left out, maybe an inner comma to make it
a tuple.

-- 
Hallvard