On Feb 20, 2008 8:47 AM, M.-A. Lemburg mal@egenix.com wrote:
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.
That is I figured no one would be willing to see urllib or urllib2 go.
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 ;-)
I actually use urllib2 over urllib because I find it easier to overload with custom HTTP headers.
In any case, deprecating a module after the jump to 3.0 is more problematic than during the major version number change.
I agree, but it is certainly doable.
How about using the following mapping:
urllib -> url.fetch urllib2 -> url.request
I can live with that. What do other people think?
-Brett