Raymond writes:
> Is there anyone else on python-dev who thinks it's a bad idea to automatically
> close reports without checking whether the issue is real?
Raymond:
I'm speaking up with some trepidation here, since I am NOT one of those
who frequently closes bugs. But I think that at least sometimes there
IS an advantage to closing old bugs.
I can envision a world in which there would be only 5-10 open bug reports
at any given time, with enough developer volunteers available to …
[View More]respond
to new reports as they come in. And I realize that we are nowhere near
such a world and we're not going to be getting there anytime soon.
But it is still the case that MOST people are intimidated by the enormous
stack of open bugs. Perhaps "intimidated" is the wrong word... what I want
to convey is that most people have no idea what's important or where to
start -- it's just too big a pile. Perhaps all of the people who would
actually work to close Python bugs are perfectly happy with the existing
system. Or perhaps we scare off some potential volunteers because they
have no idea where to start.
I've seen some systems that solve this problem by allowing users to "vote"
for favorite bugs... then you can tell the "important" bugs because they
are more likely to have lots of votes. As I see it, Facundo is using a
variant of that system. He is asking whether there is *ONE PERSON* out
there who cares enough about a bug to subscribe to it and then to respond
to his inquiry. If there's not even one such person, then he's closing
the bug (but if one such person comes along later, they can re-report it).
Sure, we may be throwing away some useful information by closing a bug
report without proper investigation. But we're not in a situation where
we are short of information... we've got plenty of information (bug
reports), what we lack is developer time. If throwing away information
helps to better focus the developer time we have, then it may be a
useful process!
And someday when nirvana arrives and there are only 5-10 open bugs, we
can send intrepid volunteers digging through the archives to examine
bugs that got closed without proper investigation. I'm not holding my
breath.
-- Michael Chermside
[View Less]
Would there be any interest in extending the compiler package with tools
for AST transformations and for emitting Python source code from ASTs?
I was experimenting with possible translations for exception chaining
and wanted to run some automated tests, so i started playing around
with the compiler package to do source-to-source transformations.
Then i started working on a way to do template-based substitution of
ASTs and a way to spit source code back out, and i'm wondering if
that might be …
[View More]good for experimenting with future Python features.
(If there's already stuff out there for doing this, let me know --
i don't intend to duplicate existing work.)
-- ?!ng
[View Less]
> > Old age and a missing OP is not sufficient reason to close a bug.
> >
> > But if closing a bug is an effective way of kicking things into life
> > again...
>
> I'm seeing this effect in a lot of bugs I closed as old ones.
That means they shouldn't have been closed and that we almost lost a valid report.
Also, for the most part, "kicking to life" means getting a qualified reviewer to take time to decide an appropriate course of action. Typically, the OP is …
[View More]not that person. Usually, the only "kick to life" we need from an OP is clarification if their post was not sufficiently specific; otherwise, they usually shouldn't have to do anything.
> Take note that for closing it, first there's a warning, and if in a
> *month* (which really happens to delay into several months, my fault)
> the interested people don't take care again of that bug...
A better use of time is to BE one of the interested people and take care of the bug. Just closing it doesn't make the problem go away.
Also, inactivity does not imply that a bug is not a recurring irritant. We encourage posters to scan existing bug reports before filing a new one. Likewise, we immediately close duplicates. If the original report then disappears without having been cleared, then we've broken our promises to the othesr who did or would have posted a more current report. The existence of an old report means the problem has been registered and is awaiting a thoughtful response. Because of the way SF is setup, the other interested people are not likely to receive your "one month warnings".
Closing reports without analyzing their contents is not progress. AFAICT, that has never been our policy. Is there anyone else on python-dev who thinks it's a bad idea to automatically close reports without checking whether the issue is real?
Raymond
[View Less]
There should be some greater care exercised in closing old bugs.
Marking them "deprecated" and then erasing them is only a good strategy
if we have no means of reproducing the error or ascertaining what the OP
was talking about.
For instance, in www.python.org/sf/640553 , it was possible for a
reviewer to directly verify whether usr/local local was still being used
in setup.py. Likewise, www.python.org/sf/728515 should not have been
closed (Martin's post could have been taken as a clue that …
[View More]the bug was
valid and simply waiting for some volunteer to submit a patch).
Old age and a missing OP is not sufficient reason to close a bug. If
the report is clear and the bug is potentially still valid, it should be
left open. Efforts to clear old bugs should focus on fixing them or
making a conscious Won't Fix decision (with old age possibly indicating
that there is not a real problem in practice).
Raymond
P.S. When setting a time deadline for an OP to respond, we should use
some terminology other than "deprecated". The word doesn't fit well and
can be confused with the unrelated topic of module or feature
deprecation.
[View Less]
Raymond Hettinger wrote:
> IMO, user input (or
> the full numeric strings in a text data file) is sacred and presumably
> done for a reason -- the explicitly requested digits should not be
> throw-away without good reason.
I still don't understand what's so special about the
input phase that it should be treated sacredly, while
happily desecrating the result of any *other* operation.
To my mind, if you were really serious about treating
precision as sacred, the result of every …
[View More]operation
would be the greater of the precisions of the
inputs. That's what happens in C or Fortran - you
add two floats and you get a float; you add a float
and a double and you get a double; etc.
> Truncating/rounding a
> literal at creation time doesn't work well when you are going to be
> using those values several times, each with a different precision.
This won't be a problem if you recreate the values
from strings each time. You're going to have to be
careful anyway, e.g. if you calculate some constants,
such as degreesToRadians = pi/180, you'll have to
make sure that you recalculate them with the desired
precision before rerunning the algorithm.
> Remember, the design documents for the spec state a general principle:
> the digits of a decimal value are *not* significands, rather they are
> exact and all arithmetic on the is exact with the *result* being subject
> to optional rounding.
I don't see how this is relevant, because digits in
a character string are not "digits of a decimal value"
according to what we are meaning by "decimal value"
(i.e. an instance of Decimal). In other words, this
principle only applies *after* we have constructed a
Decimal instance.
--
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg.ewing(a)canterbury.ac.nz +--------------------------------------+
[View Less]