[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
<wink>.
> 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 <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4