[Python-Dev] PEP 326 (quick location possibility)
Raymond Hettinger
python at rcn.com
Tue Jan 27 17:10:34 EST 2004
> What does everyone think? Thanks for reading,
> - Josiah
>
>
> 5-line replace of 758 in object.c included below for reference:
> if (v == PyMinObject || w == PyMaxObject)
> return -1;
> else if (v == PyMaxObject || w == PyMinObject)
> return 1;
> else if (Py_EnterRecursiveCall(" in cmp"))
-1 on *any* modification of the existing builtin functions.
It is best to keep the proposal pure and de-coupled by just
having a pair of objects that return always-under or always-
over in a comparision.
If you return back to that foundation, the open questions are
* putting is someplace useful, yet out of the way,
without introducing any weirdness (if there's nothing else
quite like it, it is probably a bad idea).
* determining that is actually worth it. Jeremy never needed
it in eight years, though if it had been available I'll bet
he would have used it. Even if the need arises only once a
year, then it is probably too rare (that threshold varies with
the hardness of the problem, i.e. you may only need the logging
module once per year, but when you need it, there is no cheap,
well thought-out, category killing alternative). In this case,
the problem is so immediately solvable that it hardly counts
as a minor speed bump.
My sense is that Jeremy is on target with his suggestion that this
be a recipe. We've certainly reached the point where more time
and effort has been spent discussing it than could ever be saved
by the introduction of the min/max constants.
To date, the arguments tend to emphasize purity over practicality,
and the original motivation may have been replaced by an
understandable desire to push a PEP through the acceptance stage.
IOW, "we've come this far and suffered so much" is not really
a good reason for pressing on.
Raymond Hettinger
More information about the Python-Dev
mailing list