Any ideas on how to handle urllib, urllib2, and urlparse?
Dealing with the URL-related modules is the last specific thing I want to deal with in terms of new packages. The problem is that urllib and urllib2 each have a key function that are named the same thing with slightly different parameters and returning objects that have the same base interface but are different classes and provide a different way to overload what gets returned. Doing something like: urllib -> url.fetch (not url.open since url.open.urlopen() looks weird) urllib2 -> url.fetch2 urlparse -> url.parse seems somewhat silly, but the best I can think of right now. I could ask the web-sig if they think we could try to get rid of either urllib or urllib2, but I suspect they will say no. -Brett
2008/2/20, Brett Cannon <brett@python.org>:
seems somewhat silly, but the best I can think of right now. I could ask the web-sig if they think we could try to get rid of either urllib or urllib2, but I suspect they will say no.
OTOH, I think that having a module called urllib, and other called urllib2 is a result of the evolution and not the best configuration. The web-sig or python-dev should pronounce what to do with this. IMHO, the best is to have one module, with the best of both worlds. 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). Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
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. Christian
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 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 20 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
On Feb 20, 2008 9: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.
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'm pretty sure the intent of urllib2 is to give better error messages than urllib. I only use urllib2 in my own code for that reason. (I don't remember what confusing error I got from urllib that made me switch, but I remember that there was one.) Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy
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
On Wed, Feb 20, 2008 at 9:25 PM, Brett Cannon <brett@python.org> wrote:
On Feb 20, 2008 8:47 AM, M.-A. Lemburg <mal@egenix.com> wrote:
How about using the following mapping:
urllib -> url.fetch urllib2 -> url.request
I can live with that. What do other people think?
I'm fine with it, if both packages are kept. But since it looks like urllib is considered inferior to urllib2, shouldn't it be possible to improve the latter (integrating whatever can be salvaged from urllib) and removing the former, in the spirit of Christian's suggestion ? Quentin
On Feb 20, 2008, at 5:11 PM, Quentin Gallet-Gilles wrote:
I'm fine with it, if both packages are kept. But since it looks like urllib is considered inferior to urllib2, shouldn't it be possible to improve the latter (integrating whatever can be salvaged from urllib) and removing the former, in the spirit of Christian's suggestion ?
I'd go so far as to say that any use case for urllib that can't be supported by urllib2 suggests a bug in urllib2. :-) I don't think I've encountered a situation that I couldn't solve easily with urllib2 where I'd have used urllib in the past (pre-urllib2 days). -Fred -- Fred Drake <fdrake at acm.org>
Quentin Gallet-Gilles wrote:
On Wed, Feb 20, 2008 at 9:25 PM, Brett Cannon <brett@python.org> wrote:
On Feb 20, 2008 8:47 AM, M.-A. Lemburg <mal@egenix.com> wrote:
How about using the following mapping:
urllib -> url.fetch urllib2 -> url.request
I can live with that. What do other people think?
I'm fine with it, if both packages are kept. But since it looks like urllib is considered inferior to urllib2, shouldn't it be possible to improve the latter (integrating whatever can be salvaged from urllib) and removing the former, in the spirit of Christian's suggestion ?
I wouldn't say it's inferior... it just uses a different approach (plug in handlers rather than overriding methods). BTW: Google Code Search gives 10000 hits for "import urllib2" and 38100 for "import urllib". I bet most just use urllib[2]?.urlopen() anyway, without going into any of the details. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 20 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
participants (7)
-
Brett Cannon -
Christian Heimes -
Facundo Batista -
Fred Drake -
M.-A. Lemburg -
Quentin Gallet-Gilles -
Steven Bethard