Re: [Python-Dev] uuid backward compatibility
All your replies clarifies what your comment was intended to mean, especially this one: I'd just like people who get their hands on the module to know that they can use it with 2.3. When I first read the comment, I interpretted it too broadly and took it as a requirement for compatibility. But you didn't mean it that way at all. My apology for not asking you beforehand. uuid is now removed from the dont-break-compatibility list. -- george ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
On 6/18/06, Martin v. Löwis [EMAIL PROTECTED] wrote: As for the comment: It apparently *is* misleading, George mistakenly took it as a requirement for future changes, rather than a factual statement about the present (even though it uses the tense of simple present). Anybody breaking 2.3 compatibility will have to remember to remove the comment, which he likely won't. This sentiment is puzzling to me. It seems you assume that we can trust future developers to change the code but we can't trust them to update the documentation. So we can't have documentation even if it's factually true just because someone might forget to update it? Why is the mere possibility of incorrect documentation in the future more significant than actual correct documentation in the present? Couldn't the same argument be used to support removing all documentation from all code? If you see a better way to word the comment to reduce the possibility of misunderstanding, that's cool with me. I'd just like people who get their hands on the module to know that they can use it with 2.3. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
On 6/19/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: On 6/18/06, Martin v. Löwis [EMAIL PROTECTED] wrote: As for the comment: It apparently *is* misleading, George mistakenly took it as a requirement for future changes, rather than a factual statement about the present (even though it uses the tense of simple present). Anybody breaking 2.3 compatibility will have to remember to remove the comment, which he likely won't. This sentiment is puzzling to me. It seems you assume that we can trust future developers to change the code but we can't trust them to update the documentation. It's sad but true that comments often are out of date for several releases until someone notices them. So we can't have documentation even if it's factually true just because someone might forget to update it? Why is the mere possibility of incorrect documentation in the future more significant than actual correct documentation in the present? Couldn't the same argument be used to support removing all documentation from all code? I think it has to be weighed in each case. In *this* particular case the relevance of the comment seems quite minimal and removing it seems appropriate. If you see a better way to word the comment to reduce the possibility of misunderstanding, that's cool with me. I'd just like people who get their hands on the module to know that they can use it with 2.3. Well even if the comment remains, they are going to have to try it before they can trust the comment (see above). There is lots of code in the stdlib that is compatible with Python 2.3 (or 1.5.2 for that matter). How important is it to record that fact? I'd say not at all. The Python standard library of a particular Python version shouldn't be seen as an additional way to distribute code that's intended for other versions. If you want to encourage people to use your module with older versions, the right path is to have a distribution (can be very light-weight) on your own website and add it to PyPI (Cheese Shop). You can put the same version distributed with Python 2.5 there; this isn't going to be something with maintenance and featuer evolution, presumably, since it's only needed until they catch up with 2.5 or later. If you still aren't convinced, how about a comment like this: # At the time of writing this module was compatible with Python 2.3 and later. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
Ka-Ping Yee wrote: This sentiment is puzzling to me. It seems you assume that we can trust future developers to change the code but we can't trust them to update the documentation. That's precisely my expectation. Suppose Python 3.0 unifies int and long, and deprecates the L suffix. Then, if not 0 = time_low 132L: will change to if not 0 = time_low 132: While this will work fine in Python 2.4 and onwards, it will break 2.3. Whoever is making the change won't even think of the necessity of a documentation change - after all, this is supposed to be a style change, only. People do make whole-sale style changes to the entire library from time to time. So we can't have documentation even if it's factually true just because someone might forget to update it? Sure, we can, and if you want that to, we should (you are the author, so your view is quite important), and I'll shut up. I just wanted to caution about a risk here. If you see a better way to word the comment to reduce the possibility of misunderstanding, that's cool with me. I'd just like people who get their hands on the module to know that they can use it with 2.3. I personally didn't find it misleading at all, and see no need to change it for *that* reason. I see a potential risk in it wrt. future changes, but perhaps I'm paranoid. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
Guido van Rossum wrote: # At the time of writing this module was compatible with Python 2.3 and later. :-) Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
On Mon, 19 Jun 2006, Guido van Rossum wrote: If you want to encourage people to use your module with older versions, the right path is to have a distribution (can be very light-weight) on your own website and add it to PyPI Okay, i've removed the comment and submitted the package to PyPI. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
On Sun, 18 Jun 2006, George Yoshida wrote: uuid.py says in its docstring: This module works with Python 2.3 or higher. And my question is: Do we plan to make it 2.3 compatible in future releases? If so, uuid needs to be listed in PEP 291. Otherwise, the comment is misleading. The comment isn't misleading, because the module actually does work with Python 2.3. It would only become misleading if it were later changed to break compatibility with Python 2.3 without updating the comment. I intentionally avoided breaking compatibility with Python 2.3 so that there would be just one current version of uuid.py, both in the svn repository and available for use with existing installations of Python, since Python 2.3 is so widely deployed right now. Anyway, it looks like someone has added this module to the list of backward-compatible modules in PEP 291. Regarding whether we want it to be on that list (i.e. whether or not this backward-compatibility should be retained as Python moves forward), i'm happy to have it either way. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] uuid backward compatibility
Ka-Ping Yee wrote: Anyway, it looks like someone has added this module to the list of backward-compatible modules in PEP 291. Regarding whether we want it to be on that list (i.e. whether or not this backward-compatibility should be retained as Python moves forward), i'm happy to have it either way. In that case, I think we shouldn't require 2.3 compatibility. There is no reason to deliberately break it either, of course. As for the comment: It apparently *is* misleading, George mistakenly took it as a requirement for future changes, rather than a factual statement about the present (even though it uses the tense of simple present). Anybody breaking 2.3 compatibility will have to remember to remove the comment, which he likely won't. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
