random vs whrandom (was RE: [Python-Dev] Unittests) (original) (raw)

Tim Peters tim.one@comcast.net
Fri, 12 Apr 2002 15:51:47 -0400

[Neal Norwitz, working hard on deprecation issues]

I hate to make this a death of a thousand cuts, but ...

... Should User{Dict, List, String} be deprecated since one can derive from {dict, list, str}?

No, they're still essential. The advice is to derive from a builtin only if all you want to do is add new methods and/or attributes. Trying to override existing getitem etc can be very frustrating, because the core implementation often skips the expensive OO dance of looking for overrides of basic methods (e.g., PyList_SET_ITEM(op, i, v) is currently the straight one-liner

(((PyListObject *)(op))->ob_item[i] = (v))

and would be enormously slower if it first had to see whether this is a list subtype overriding setitem). But the UserXYZ classes are reliably slow .

Or perhaps scheduled to be deprecated at some point in the future?

Not in the foreseeable future.

Should library uses of UserDict (List & String aren't used) be converted to new instances deriving from {}?

No, that would break existing code because the core so often ignores the possibility of overrides.

How should deprecated classes/functions/methods be handled? ... random.Random.randint()

I recommend to rehabilitate (un-deprecate) this one. It's very popular on the Tutor list, and a newbie who thinks dice faces are numbered from 1 thru 6 isn't in dire need of re-education in my eyes .