[Python-Dev] handling the granularity of possible Py3K warnings in 2.6

[Brett Cannon]

My rewrite of import is written for 2.6.  But I am going to try to
bootstrap it into 3.0.  But I want to bootstrap into 2.6 if it works
out well in 3.0.  That means coding in 2.6 but constantly
forward-porting to 3.0.  In other words I am going to be a guinea pig
of our transition plan.

And being the guinea pig means I want to know where we want to take
the Py3K warnings in 2.6.  As of right now the -3 option causes some
DeprecationWarnings to be raised (mostly about callable and
dict.has_key).  But I was thinking that a certain level of granularity
existed amongst what should be warned against.

There is syntactic vs. semantic.  For syntactic there is stuff you can
do in versions of Python older than 2.6 (e.g., backtick removal),
stuff you can only do in 2.6 (e.g., new exception syntax), or stuff
that you can't do at all without a __future__ statement (e.g.,
'print').

For semantics, there is removal (e.g., callable), and then there is
new semantics (dict.items).

What I was thinking was having these various types of changes be
represented by proper warnings.  That allows for using the -W option
to control what warnings you care about.

So I envision something like:

+ Py3KWarning
   + Py3KSyntaxWarning
      + some reasonable name for stuff that can be done in 2.6.
          + some name for stuff that can be done in older than 2.6.
      + something for stuff like the 'print' removal that require a
__future__ statement.
   + Py3KSemanticWarning
       + Py3KDeprecationWarning
       + Py3KChangedSemanticsWarning (or whatever name you prefer)


The key point is that when I am forward-porting I want to easily tell
what syntax changes I can deal with now in older, e.g. 2.5 code, stuff
that I can change directly in 2.6, and stuff that requires 2to3 or a
__future__ statement.  Similar idea for semantic changes.  That way I
can do this all in steps.

Does this sound reasonable to people at all?

-Brett