[Python-Dev] Deprecating modules (python-dev summary for early Dec, 2004)

[Jim Jewett]

> 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