This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients benjamin.peterson, eric.araujo, hfuru, loewis
Date 2010-10-12.17:23:59
SpamBayes Score 2.451882e-10
Marked as misclassified No
Message-id <4CB499AE.4010304@v.loewis.de>
In-reply-to <1286902919.1.0.34878084256.issue10070@psf.upfronthosting.co.za>
Content
> 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)?

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.

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

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.

In fact, I also avoid writing code explicitly so that it works
unmodified on Python 3 if I know that 2to3 will fix it.

There has been a long-standing request to suppress 2to3 in certain
expressions in cases where the 2to3 conversion would actually be
incorrect. However, this does not seem to be the motivation here.
History
Date User Action Args
2010-10-12 17:24:02loewissetrecipients: + loewis, hfuru, benjamin.peterson, eric.araujo
2010-10-12 17:23:59loewislinkissue10070 messages
2010-10-12 17:23:59loewiscreate