This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nedds
Recipients brett.cannon, collinwinter, nedds, rhettinger
Date 2008-08-21.15:24:57
SpamBayes Score 3.6269217e-08
Marked as misclassified No
Message-id <1219332298.81.0.654583356675.issue2876@psf.upfronthosting.co.za>
In-reply-to
Content
I've been thinking about this a bit, and I don't see how handling it
should be all that different from handling module renaming. 

For import UserDict, we can just change UserDict to collections and deal
with UserDict.UserDict with a deprecation warning and
UserDict.IterableUserDict and UserDict.Mixin with transformations to
collections.UserDict and collections.MutableMapping.

For from imports, we can raise the deprecation warning on UserDict, and
otherwise change from UserDict import ... to from collections import ...
and then for non-import appearances of UserDict, IterableUserDict, and
Mixin rename or raise a deprecation warning as appropriate.

For the other import cases, similar things could be done.

I think the old version of fix_imports, which had support like this,
would basically be all that we need. I should be able to mimic that
functionality, but also make it more scalable than the previous version.

Is there something I'm missing here about the difference between modules
and classes? From the use-cases I've observed of UserDict, it seems like
this functionality would be sufficient.
History
Date User Action Args
2008-08-21 15:24:59neddssetrecipients: + nedds, brett.cannon, collinwinter, rhettinger
2008-08-21 15:24:58neddssetmessageid: <1219332298.81.0.654583356675.issue2876@psf.upfronthosting.co.za>
2008-08-21 15:24:58neddslinkissue2876 messages
2008-08-21 15:24:57neddscreate