Deprecating modules (python-dev summary for early Dec, 2004)
It was also agreed that deleting deprecated modules was not needed; it breaks code and disk space is cheap.
It seems that no longer listing documentation and adding a deprecation warning is what is needed to properly deprecate a module. By no longer listing documentation new programmers will not use the code since they won't know about it.[*] And adding the warning will let old users know that they should be using something else.
[* Unless they try to maintain old code. Hopefully, they know to find the documentation at python.org.] Would it make sense to add an attic (or even "deprecated") directory to the end of sys.path, and move old modules there? This would make the search for non-deprecated modules a bit faster, and would make it easier to verify that new code isn't depending (perhaps indirectly) on any deprecated features. New programmers may just browse the list of files for names that look right. They're more likely to take the first (possibly false) hit if the list is long. I'm not the only one who ended up using markupbase for that reason. Also note that some shouldn't-be-used modules don't (yet?) raise a deprecation warning. For instance, I'm pretty sure regex_syntax and and reconvert are both fairly useless without deprecated regex, but they aren't deprecated on their own -- so they show up as tempting choices in a list of library files. (Though reconvert does something other than I expected, based on the name.) I understand not bothering to repeat the deprecation for someone who is using them correctly, but it would be nice to move them to an attic. Bastion and rexec should probably also raise Deprecation errors, if that becomes the right way to mark them deprecated. (They import fine; they just don't work -- which could be interpreted as merely an "XXX not done yet" comment.) -jJ
Jim> Would it make sense to add an attic (or even "deprecated") Jim> directory to the end of sys.path, and move old modules there? This Jim> would make the search for non-deprecated modules a bit faster, and Jim> would make it easier to verify that new code isn't depending Jim> (perhaps indirectly) on any deprecated features. That's what lib-old is for. All people have to do is append it to sys.path to get access to its contents: % python Python 2.5a0 (#72, Jan 20 2005, 20:14:27) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import glob >>> for f in glob.glob("/Users/skip/local/lib/python2.5/lib-old/*.py"): ... print f ... /Users/skip/local/lib/python2.5/lib-old/addpack.py /Users/skip/local/lib/python2.5/lib-old/cmp.py /Users/skip/local/lib/python2.5/lib-old/cmpcache.py /Users/skip/local/lib/python2.5/lib-old/codehack.py /Users/skip/local/lib/python2.5/lib-old/dircmp.py /Users/skip/local/lib/python2.5/lib-old/dump.py /Users/skip/local/lib/python2.5/lib-old/find.py /Users/skip/local/lib/python2.5/lib-old/fmt.py /Users/skip/local/lib/python2.5/lib-old/grep.py /Users/skip/local/lib/python2.5/lib-old/lockfile.py /Users/skip/local/lib/python2.5/lib-old/newdir.py /Users/skip/local/lib/python2.5/lib-old/ni.py /Users/skip/local/lib/python2.5/lib-old/packmail.py /Users/skip/local/lib/python2.5/lib-old/Para.py /Users/skip/local/lib/python2.5/lib-old/poly.py /Users/skip/local/lib/python2.5/lib-old/rand.py /Users/skip/local/lib/python2.5/lib-old/statcache.py /Users/skip/local/lib/python2.5/lib-old/tb.py /Users/skip/local/lib/python2.5/lib-old/tzparse.py /Users/skip/local/lib/python2.5/lib-old/util.py /Users/skip/local/lib/python2.5/lib-old/whatsound.py /Users/skip/local/lib/python2.5/lib-old/whrandom.py /Users/skip/local/lib/python2.5/lib-old/zmod.py That doesn't help for deprecated extension modules, but I think they are much less frequently candidates for deprecation. Skip
On Tue, 25 Jan 2005 16:21:34 -0600, Skip Montanaro
Jim> Would it make sense to add an attic (or even "deprecated") Jim> directory to the end of sys.path, and move old modules there? This Jim> would make the search for non-deprecated modules a bit faster, and Jim> would make it easier to verify that new code isn't depending Jim> (perhaps indirectly) on any deprecated features.
That's what lib-old is for. All people have to do is append it to sys.path to get access to its contents:
That seems to be for "obsolete" modules. Should deprecated modules be moved there as well? I had proposed a middle ground, where they were moved to a separate directory, but that directory was (by default) included on the search path. Moving deprecated modules to lib-old (not on the search path at all) seems to risk breaking code. -jJ
participants (2)
-
Jim Jewett -
Skip Montanaro