On 1/1/07, Anthony Baxter <[EMAIL PROTECTED]> 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
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
