[Python-Dev] Rounding Decimals

[Jeffrey Yasskin]

On Jan 6, 2008 10:51 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Jeffrey Yasskin]
> >> > I'm not
> >> > sure exactly what you're objecting to. Could you be more precise?
> >>
> >> You note said: "I'll implement Context.round() in a separate patch. Comment away."
> >
> > Oh, sorry for not being clear then. I don't intend to write or discuss
> > that separate patch until this one's approved and submitted. I think
> > it's worth discussing eventually, but this change is more important. I
> > mentioned this sentiment at http://bugs.python.org/msg59417 too, but
> > clearly wasn't explicit enough in either case.
>
> It's hard to keep up with all of these patches and I'm growing concerned
> that some will sneak by.

You're certainly right to be concerned. The most significant patch,
the original backport of 3141, _did_ sneak through. The only email
I've gotten about it has been in response to my question about a
detail. I don't know how I could have made it more obvious though:
nobody who suggested the backport (http://bugs.python.org/issue1623)
seemed to think it would be contentious enough to suggest emailing
this list first. Since then, I've tried to keep things transparent by
suggesting that you add yourself to the nosy list of
http://bugs.python.org/issue1623, which is where I'll post any patches
before thinking about committing them.

> In the case of complex proposals, it is often
> helpful to have a patch that we can discuss concretely, but in the case of
> simple ones like this, they just clutter to patch tracker.  There's no need
> to create the patch until the idea has been discussed.

I always like to have a patch around because abstract discussions,
even (especially?) on simple topics, have a tendency to run off into
the weeds. A patch keeps things focused and moving forward.

> In the case of Context.round(), I've already advised against it.
> So, I'm not sure why you still intend write a separate patch
> and bring it back up for discussion.  Ideally, it should die right now.

You advised against it. Tim, Mark, and glyph advised for something
like it. I think it's consistent with the fact that most operations on
Decimal instances are mirrored on Context instances, and __round__
will be an operation on Decimal instances. That doesn't sound like
enough agreement to simply drop the discussion.

> The sentiment is unchanged -- please do not build-out the API for the
> decimal module.  It is intended to be minimal and needs to stay that
> way.  Further additions will only make it harder to use, harder to
> maintain, and will complicate efforts to rewrite the module in C.

I am not building out the decimal API. I am adding enough methods to
maintain the comment that "Decimal floating point objects share many
properties with the other builtin numeric types such as float and int.
All of the usual math operations and special methods apply." in both
2.6 and 3.0. After that's done, I am interested in talking about
adding one method that 3 people on this list have been interested in.
I understand that you need to be vigilant against extraneous methods,
but I'm really not just adding these on a whim.

On Jan 6, 2008 11:28 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Jeffrey Yasskin]
> > Given Guido's agreement, expect another version of this patch with
> > only __trunc__.
>
> Why is __trunc__ being backported?  Is a trunc() builtin being backported?  What is the point for a synonym for int() and __int__ in
> Py2.6.
>
> Unless I'm missing something, this doesn't improve Py2.6 in the least.

The trunc() builtin was backported in
http://svn.python.org/view?rev=59671&view=rev and hasn't been rolled
back. All of the reasons to include trunc() in 3.0 apply to 2.6. A
couple that I like are: if trunc had been around in the beginning,
__index__ would have been unnecessary; and the name says what it's
doing, unlike int(). I don't know what Guido's reasoning was for
accepting it into the PEP.

-- 
Namasté,
Jeffrey Yasskin