Terry J. Reedy <tjre...@udel.edu> added the comment:
Tom, I appreciate your taking the time to help us improve our Unicode story. I
agree that the compromises made a decade ago need to be revisited and revised.
I think it will help if you better understand our development process. Our
current *intent* is that 'Python x.y' be a fixed language and that 'CPython
x.y.0', '.1', '.2', etc be increasingly (and strictly -- no regressions) better
implementations of Python x.y. (Of course, the distribution and installation
names and up-to-now dropping of '.0' may confuse the distinction, but it is
real.) As a consequence, correct Python x.y code that runs correctly on the
CPython x.y.z implementation should run correctly on x.y.(z+1).
For the purpose of this tracker, a behavior issue ('bug') is a discrepancy
between the documented intent of a supported Python x.y and the behavior of the
most recent CPython x.y.z implementation thereof. A feature request is a design
issue, a request for a change in the language definition (and in the
corresponding .0 implementation). Most people (including you, obviously) that
file feature requests regard them as addressing design bugs. But still,
language definition bugs are different from implementation bugs.
Of course, this all assumes that the documents are correct and unambiguous. But
accomplishing that can be as difficult as correct code. Obvious mistakes are
quickly corrected. Ambiguities in relation to uncontroversial behavior are
resolved by more exactly specifying the actual behavior. But ambiguities about
behavior that some consider wrong, are messy. We can consult the original
author if available, consult relevant tests if present, take votes, but some
fairly arbitrary decision may be needed. A typical response may be to clarify
behavior in the docs for the current x.y release and consider behavior changes
for the next x.(y+1) release.
So the answer to your question, "Do we fix bugs?", is that we fix doc and
implementation behavior bugs in the next micro x.y.z behavior bug-fix release
and language design bugs in the next minor x.y language release. But note that
language changes merely have to be improvements for Python in the future
without necessarily worrying about whether a design decision made years ago was
or is a 'bug'.
The purpose of me discussing or questioning the 'type' of some of your issues
is to *facilitate* change by getting the issue on the right track, in relation
to our development process, as soon as possible.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
