On Fri, Jul 11, 2008 at 12:26 PM, Adam Olsen <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 7:02 AM, Steve Holden <[EMAIL PROTECTED]> wrote: >> Benjamin Peterson wrote: >>> >>> On Fri, Jul 11, 2008 at 6:24 AM, Raymond Hettinger <[EMAIL PROTECTED]> >>> wrote: >>>> >>>> Some effort needs to be made to clear the standard library of -3 >>>> warnings. >>>> Running -3 on production code usually involves exercising library code >>>> so >>>> the useful result is obscured by Python complaining about itself. Since >>>> that use case involves the users own tests, I don't think the effort >>>> needs >>>> to be extended to our own unittest suite. But the rest of the library >>>> could >>>> likely benefit from a good -3 cleanup. >>> >>> Yes, indeed. We should make sure, however, that the changes in the 2.6 >>> libraries are the absolute minimum to get the job done. (I'm trying to >>> pretend like this isn't violating the prohibition on all-inclusive >>> overhauls in the stdlib.) >>> >> The prohibition is on *gratuitous* changes, basically along the lines of "if >> it ain't broke, don't fix it". The stdlib is definitely broken if it raises >> warnings of that kind. > > Is the stdlib broken or is it the warnings that are broken?
Nothing is broken, per se, but the stdlib emits a ton of warnings through basic usage for Py3K-related changes. We are telling people to run their code in 2.6 with -3 and to eliminate all warnings in order to have 2to3 work to transition to 3.0. Having the stdlib itself emit warnings is just not reasonable. > The code > is just fine in 2.6. Adding pragmas to disable warnings would be just > fine. Or we could hardcode some warnings as "already seen". > No, we should eat our own dog food and transition the code over. If anything it will help with code maintenance between 2.x and 3.x. -Brett _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
