Christian Heimes wrote:
Facundo Batista wrote:
What to do with the methods that will be lost because of keeping a slightly different one with the same functionality? We could keep them with a deprecation warning, or simply let them disappear (+0 for the former, even considering we're in 3k).
Merging urllib and urllib2 into a completely new module with a (although slightly) different API is a good thing. But it also increases the burden and workload for Python users. We should keep the original modules around if a change can't be handled by a 2to3 fixer. We can always deprecate a module for 3.1.
For urllib/urllib2 I propose:
- merge the functionality into a new, improved module
- keep the original ones around for 3.0 and schedule them for removal in
3.1.
I'm not sure that would work: urllib is one of the most used modules in Python when it comes to doing even only slightly web-related work.
I've never used urllib2 and am not sure what the reason was for adding it. It doesn't appear to offer more or better things than urllib... to late to argue, I guess ;-)
In any case, deprecating a module after the jump to 3.0 is more problematic than during the major version number change.
How about using the following mapping:
urllib -> url.fetch urllib2 -> url.request