On Tue, Nov 10, 2009 at 5:31 AM, Guido van Rossum <gu...@python.org> wrote: [snip] > In the balance, I think it's easy enough to find these things by using > the version that actually breaks things. If you are your only > customer, until then, there's little benefit in fixing the warnings > ahead of time (except perhaps for learning -- but, strangely, there > are ways of learning about programming besides trying things out :-). > If you have other customers, you should get used to testing with the > latest version of Python anyway -- running without warnings in a > previous version really isn't a good enough test for future > compatibility. > > -- > --Guido van Rossum (python.org/~guido) >
Yeah, it's easy to find and fix the bugs using the version that incurs them. I'm not worried about that, I'm more worried about how information will spread, a lot of pythonistas I know won't learn about deprecations until their program is broken. Deprecation warnings spread the word more elegantly and faster than hard deprecations IMO. I guess an upside to silent warnings would be that we could have a lot more of them. It could be nice if pylint was integrated as a warning level, lets say with 2 popular conventions in the std-lib. I personally always maximize the warning level on my C compiler and I like the insight. --yuv _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
