classification
Title: Mark the compiler package as deprecated
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: benjamin.peterson Nosy List: benjamin.peterson, brett.cannon, exarkun, ezio.melotti, georg.brandl
Priority: release blocker Keywords:

Created on 2009-09-04 14:05 by exarkun, last changed 2010-03-18 23:13 by benjamin.peterson. This issue is now closed.

Messages (10)
msg92254 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2009-09-04 14:05
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.
msg92263 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-09-04 18:58
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.
msg92271 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2009-09-04 22:25
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.
msg92283 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-09-05 17:08
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.
msg92284 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2009-09-05 17:48
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.
msg92285 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2009-09-05 17:49
Oops.  I wrote "In contract" in my previous message.  I meant "In contrast".
msg92289 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-09-05 18:38
"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.
msg97693 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2010-01-13 07:11
This can be reconsidered now that the DeprecationWarnings are silenced by default (see #7319).
msg97934 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-01-17 08:33
+1.
msg101291 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-03-18 23:13
Promoted warning to full DeprecationWarning in r79078.
History
Date User Action Args
2010-03-18 23:13:14benjamin.petersonsetstatus: open -> closed
resolution: accepted
messages: + msg101291
2010-01-17 08:33:42georg.brandlsetmessages: + msg97934
2010-01-13 18:47:14brett.cannonsetpriority: normal -> release blocker
2010-01-13 07:11:25ezio.melottisetstatus: closed -> open
priority: normal

nosy: + ezio.melotti
messages: + msg97693

resolution: wont fix -> (no value)
2009-09-05 18:38:03georg.brandlsetmessages: + msg92289
2009-09-05 17:49:43exarkunsetmessages: + msg92285
2009-09-05 17:48:54exarkunsetmessages: + msg92284
2009-09-05 17:08:09georg.brandlsetnosy: + georg.brandl
messages: + msg92283
2009-09-04 22:25:59exarkunsetmessages: + msg92271
2009-09-04 18:58:39brett.cannonsetstatus: open -> closed

nosy: + brett.cannon
messages: + msg92263

resolution: wont fix
2009-09-04 15:44:11georg.brandlsetassignee: benjamin.peterson

nosy: + benjamin.peterson
2009-09-04 14:05:27exarkuncreate