According to http://docs.python.org/library/compiler.html, the compiler
package is deprecated.  However, importing the compiler package does not
emit a deprecation warning.  It should, to convey this information to
people who are actually trying to use the package.

The package is not going to be removed from 2.x at this point since 2.7 
will most likely be the last major release of the line. But it does have a 
Py3k warning which is good enough in this situation.

Bugs are no longer being fixed in the compiler package.  To me, that
says it should be regular-deprecated.  People with no short term plans
of switching to Python 3 will still want to avoid the compiler package.
 They should be told about the deprecation too, and they're not going to
be turning on Py3k warnings.

The compiler package is surprisingly often used; we already had
complaints when (I think) 2.6 began emitting lots of new
DeprecationWarnings, but for modules/APIs whose replacements was
straightforward.

Replacing usage of the compiler package is usually not straightforward,
since the AST differs from Python's own, and the API for accessing it
even more.  This means that lots of code will continue spewing out these
warnings.

However, a more visible notice in the docs would not hurt, I guess.

Hi Georg, thanks for your comment.

I'm not sure I fully understand, though.

The compiler package is widely used, okay.  So I suppose that means that
the desire here is to make those users happy?

But the compiler package is deprecated, and has known bugs which will
not be fixed.

But to avoid making people unhappy, using the compiler package shouldn't
emit a deprecation warning (despite the fact that it is deprecated). 
Because... seeing the message will make people unhappy?  In contract
specifically to the fact that bugs in the package are going to remain
unfixed and a replacement is being put forward.  It's the message that
is going to cause the upset?

Thanks for any clarification.

Oops.  I wrote "In contract" in my previous message.  I meant "In contrast".

"Bugs are not fixed" is somewhat misleading -- I assume you're referring
to bugs like the one I closed recently. Those are all bugs that have
been in the compiler package for ages, and users that hit them know them
or work around them.  If a regression comes up, it should be fixed IMO.

The only way to make the compiler users happy would be to add it back,
fully supported, to Python3 :)

If you want to understand my reasoning: I want to avoid a situation like
a few months ago, when Python 2.6 was released -- people claimed e.g.
the latest Mercurial release at that time wasn't compatible with 2.6
because it emitted quite a few DeprecationWarnings.  This statement is
not true, of course, but this is how users see it.  In that case, it was
easy for Mercurial to "fix" because all the deprecated features could be
replaced without effort.  For libraries/programs that use the compiler
package, this won't be effortless and many maintainers may not be able
to spend the time and effort to "fix" that.

Also, if you look at other modules removed in Py3k, like "new" or
"rfc822", they all only raise a Py3k deprecation warning.

This can be reconsidered now that the DeprecationWarnings are silenced by default (see #7319).

+1.

Promoted warning to full DeprecationWarning in r79078.