[Python-3000] PEP 3108: Standard Library Reorganization

[Brett Cannon]

On 1/1/07, Anthony Baxter <anthony at interlink.com.au> wrote:
>
> On Tuesday 02 January 2007 11:52, Giovanni Bajo wrote:
> > Brett Cannon wrote:
> > > Modules will be renamed in Python 2.6 .  The original names of
> > > the modules will still work but will raise ImportWarning upon
> > > import.  The refactoring tool for transitioning to Python 3.0
> > > will refactor imports that use the original names to the new
> > > names.
> >
> > Does that mean that a very large amount of existing Python code
> > will raise an ImportWarning under Python 2.6? I don't think this
> > is acceptable. Why should the users be bothered with deprectation
> > warnings related to Python 3.0? Surely the *developers* are the
> > only ones interested in this.
> >
> > A PendingDeprecationWarning is fine in this case too I guess. Or
> > you could introduce a specific Py3kDeprecationWarning, turned on
> > with a mystical -3 command line option (in which we can join all
> > the features to help porting source code to Py3k).
>
> I could not agree more. The list of modules Brett gave covers enough
> that pretty much every single piece of code I have will need to be
> edited. Worse yet, I _can't_ edit it and change it to the new names
> unless I want to abandon pre-2.6 compatibility. This is completely
> unacceptable. Living with a huge spew of warnings is not an
> acceptable outcome - for those of us running production systems in
> Python, a warning should be an indication of something to be fixed,
> not pointless log-filler.
>
> I'd like to suggest that any warnings about 3.0 compat _not_ be
> issued by default, if the fix results in code that fails with
> earlier 2.x releases.
> Even if there's a way to fix a compat issue for pre-2.6, if it's a
> very common construct then the warning should also be suppressed by
> default. A -3 flag (or whatever it ends up being) should be used to
> enable these warnings.
>
> Making 2.6 "the release where everyone's code starts spewing pages
> of warnings" is a bad bad thing. It will convey a terrible
> perception of Python amongst people who use it. Vendors who
> distribute code to other users will also be most unimpressed. You
> and I might know that a warning is just a warning, but many other
> people will not realise that, and will think "ohmygod - 2.6 broke
> my code!"


OK, the argument works for me.  Would you prefer a Py3K-specific warning
that is like PendingDeprecationWarning and thus normally silenced or just
stick with PendingDeprecationWarning?

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070101/9928eb57/attachment.htm