random vs whrandom (was RE: [Python-Dev] Unittests) (original) (raw)
Neal Norwitz neal@metaslash.com
Fri, 12 Apr 2002 15:27:40 -0400
- Previous message: [Python-Dev] Re: Deprecation process (random vs whrandom)
- Next message: random vs whrandom (was RE: [Python-Dev] Unittests)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guido van Rossum wrote:
> I added warnings to statcache & xmllib which are deprecated in the docs. > Any others need to be done? Should statcache be removed from testsundry? > Should any modules be moved into lib-old? posixfile? A good exercise would be to do a 1-minute review of every module in the library and decide for yourself if you'd deprecate it if you were BDFL. I'll gladly review the list.
Here's a long list of issues for dealing with deprecation in the standard library.
Recommend to move to lib-old:
FCNTL deprecated 2001/05/09 - libundoc.tex (under obsolete-modules) gopherlib in pep 4, before oct 2000 - not deprecated in code or doc posixfile in pep 4, before oct 2000 - not deprecated in code, 1.5 in docs regsub deprecated 2000/12/19 - libundoc.tex (under obsolete-modules) stringold not deprecated in code - not documented anywhere tzparse libundoc.tex (under obsolete-modules) TERMIOS deprecated 2001/02/27 - not documented anywhere
Python modules I recommend for deprecation:
audiodev
C modules I recommend for deprecation (not sure what to do to deprecate these, update PEP 4 and comment out of Setup?): dlmodule mpzmodule pcremodule pypcremodule rotormodule stropmodule yuvconvert
SGI specific modules, is there any use for these anymore???
almodule cdmodule clmodule flmodule fmmodule imgfile sgimodule svmodule
Should there be a deprecation schedule or estimate for modules
we know will become obsolete to give an approximate time?
Regex comes to mind.
Should User{Dict, List, String} be deprecated since one can derive
from {dict, list, str}?
Or perhaps scheduled to be deprecated at some point in the future?
Should library uses of UserDict (List & String aren't used)
be converted to new instances deriving from {}?
UserDict is used in:
cgi.FormContentDict
cookie.Morsel
cookie.BaseCookie
os._Environ
weakref.WeakKeyDictionary
weakref.WeakValueDictionary
How should deprecated classes/functions/methods be handled? htmllib.HTMLParser.do_nextid() pty.master_open() pty.slave_open() pstats.Stats.ignore() random.Random.randint() rfc822.AddrlistClass string.zfill()
How should deprecated parameter usage be handled? (ie, can call with no params, but should always use 1+ params) Cookie.Cookie()
Should we (re)move everything that was deprecated in 1.5.2/1.6 or earlier? Or perhaps even 2.0? This info is from the docs:
array.read() - 1.5.1
array.write() - 1.5.1
cmpcache - 1.6
cmp - 1.6
operator.sequenceIncludes - 2.0
operator.isCallable - 2.0
posixfile - 1.5
profile.Stats.ignore() - 1.5.1
random.Random.randint() - 2.0
string.atof() - 2.0
string.atoi() - 2.0
string.atol() - 2.0
sys.exc_traceback - 1.5
tempfile.template - 2.0
sys.exit_thread - 1.5.2
Neal
- Previous message: [Python-Dev] Re: Deprecation process (random vs whrandom)
- Next message: random vs whrandom (was RE: [Python-Dev] Unittests)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]