On Thu, Nov 5, 2009 at 15:26, Guido van Rossum <gu...@python.org> wrote: > On Thu, Nov 5, 2009 at 3:21 PM, Jesse Noller <jnol...@gmail.com> wrote: >> On Thu, Nov 5, 2009 at 5:53 PM, Dirkjan Ochtman <dirk...@ochtman.nl> wrote: >>> On Thu, Nov 5, 2009 at 23:05, Guido van Rossum <gu...@python.org> wrote: >>>> I haven't seen substantial opposition against the PEP -- in fact I >>>> can't recall any, and many people have explicitly posted in support of >>>> it. So unless opposition suddenly appears in the next few days, I'll >>>> move it to the Accepted state next Monday. >>> >>> Let me state first, I think the PEP is great, and I have no objection >>> to its current form. >>> >>> I do have one qualm, where I wonder if the PEP shouldn't be a little >>> stricter. As a gentoo developer and Mercurial maintainer, most of the >>> pain in the recent migration towards 2.6 has not been in language >>> changes, but in the standard library. Unfortunately, it's exempt from >>> the moratorium in the PEP. >>> >>> Which makes me wonder, why are we not adding another moratorium, on >>> deprecations in the standard library? In other words, let's not >>> deprecate things like md5 or sha or the popen family of functions, but >>> keep all of that as it is, for both 2.x and 3.x, so people can direct >>> their energy towards other things (hopefully porting their 2.x >>> codebase to 3.x). >>> >>> The standard library has already been through a lot of evolution in >>> the 2.x to 3.x transition, so one might assume there's not a lot of >>> stuff in the 3.x stdlib that would need deprecation in the short term. >>> And for 2.x, well, I'd certainly hope we don't need to deprecate much >>> more there before it finally gets EOL'ed, so it should be a relatively >>> light maintenance load to bear. >>> >>> Is this just crazy talk? >>> >>> Cheers, >>> >>> Dirkjan >>> >> >> I'm against restricting deprecation warnings within the stdlib as part >> of this. I actually want more things cleaned up and possibly >> deprecated. That being said, a deprecation warning just means we will >> remove it One Day - anything being deprecated will need a PEP and >> follow the long path to actual removal. >> >> So, -1 from me ;) >> >> jesse > > Actually, I think Dirkjan has a point. I'm not sure that we need > another moratorium (that's a rather dramatic kind of decision which > should be very rare indeed) but I do agree that deprecations are often > more of a pain than they're worth. > > For example, take the deprecation of the md5 and sha modules in Python > 2.6. They make it a bit of a pain to write code that *cleanly* > supports Python 2.4 (doesn't have hashlib) through 2.6 (warns when > importing md5 instead of hashlib). You can silence the warning, but > that is in itself not particularly clean, and users really hate having > the warnings. > > I have come to the conclusion that there are better ways to > pre-announce that a module is going to disappear instead of > deprecation warnings. >
What exactly are those better ways? Document as deprecated only? -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
