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 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.)
> > 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 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?
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 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).
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
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 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
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |