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
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
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
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,
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:
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.
--
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
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
