what level of backward compatibility? how
urlparse.py uses lists of strings to indicate which protocols have which properties. For instance: uses_relative = ['ftp', 'http', 'gopher', 'nntp', 'imap', 'wais', 'file', 'https', 'shttp', 'mms', 'prospero', 'rtsp', 'rtspu', ''] Logically, these are sets, rather than lists. CVS change 143 changed the lists to sets. Unfortunately, it breaks client code that did urlparse.uses_relative.append('my_protocol') which was as close to a documented API as existed. (1) Is this an OK breakage with the 2.4 switch? (2) If not, should this change be backed out, or replaced with some set subclass that takes a few of the list methods? -jJ
Jewett, Jim J wrote:
Unfortunately, it breaks client code that did
urlparse.uses_relative.append('my_protocol')
which was as close to a documented API as existed.
Why are you saying that (or: what does that mean)? The uses_relative attribute of urlparse was never documented, AFAICT.
(1) Is this an OK breakage with the 2.4 switch?
If it wasn't documented, it is OK to break it, but it should be mentioned in whatsnew24.tex. Regards, Martin
Jewett, Jim J wrote:
Unfortunately, it breaks client code that did
urlparse.uses_relative.append('my_protocol')
which was as close to a documented API as existed.
Why are you saying that (or: what does that mean)?
The uses_relative attribute of urlparse was never documented, AFAICT.
(1) Is this an OK breakage with the 2.4 switch?
If it wasn't documented, it is OK to break it, but it should be mentioned in whatsnew24.tex.
I have a different POV. I don't think there is a compelling reason to change this attribute into a set (I doubt it's so time-critical as to make a difference) and given that the attribute isn't flagged as "private" by having a name starting with underscore, I think the change ought to be reverted. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Friday 07 May 2004 12:29 am, Guido van Rossum wrote:
I have a different POV. I don't think there is a compelling reason to change this attribute into a set (I doubt it's so time-critical as to make a difference) and given that the attribute isn't flagged as "private" by having a name starting with underscore, I think the change ought to be reverted.
I'd like to suggest that we either document the "right way" to extend the information to support new URL schemes, and possibly add a function as the way to do that. Having to update a whole set of lists from outside the module seems a poor and error-prone way to do this. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
On Fri, 2004-05-07 at 02:10, Fred L. Drake, Jr. wrote:
On Friday 07 May 2004 12:29 am, Guido van Rossum wrote:
I have a different POV. I don't think there is a compelling reason to change this attribute into a set (I doubt it's so time-critical as to make a difference) and given that the attribute isn't flagged as "private" by having a name starting with underscore, I think the change ought to be reverted.
I'd like to suggest that we either document the "right way" to extend the information to support new URL schemes, and possibly add a function as the way to do that. Having to update a whole set of lists from outside the module seems a poor and error-prone way to do this.
It sounds like appending to the list was the right way up until now. That is, extending the list of protocols is a reasonable feature and using a list with a non-underscore name provided one obvious was to do that. Jeremy
I have a different POV. I don't think there is a compelling reason to change this attribute into a set (I doubt it's so time-critical as to make a difference) and given that the attribute isn't flagged as "private" by having a name starting with underscore, I think the change ought to be reverted.
[Fred]
I'd like to suggest that we either document the "right way" to extend the information to support new URL schemes, and possibly add a function as the way to do that. Having to update a whole set of lists from outside the module seems a poor and error-prone way to do this.
Let's be conservative and not change the code just because the (rarely-needed) API is a bit ugly. Let's just document the existing way and not declare old code that uses it out of date. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
"Martin v. Löwis" -
Fred L. Drake, Jr. -
Guido van Rossum -
Jeremy Hylton -
Jewett, Jim J