[Python-Dev] [Python-3000] Rounding Decimals

[Guido van Rossum]

On Jan 6, 2008 7:40 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Jeffrey Yasskin]
> > The other 3 methods
> > specified by PEP 3141 aren't strictly necessary for 2.6, but they will
> > be needed for 3.0. I'd rather not make the two versions of Decimal
> > gratuitously different, so this patch puts them in the 2.6 version
> > too.
>
> If I understand you correctly, then the patch backports magic methods that do not have corresponding invocation methods in Py2.6.
> So, they are basically useless. If that's true, then the patch is clutter -- it makes 2.6 less desirable.  It is not obvious to me
> how this will help someone transition to Py3.0.  I'm curious to hear how Guido makes the call on this.
>
> Also, the goal of keeping versions identical across 2.6 and 3.0 is at odds with previous discussions where I believe we said that
> that is *not* the goal and will likely not even be possible in many cases.  Besides, if the invocation of the magic methods is
> different in 3.0, how are you going to keep the test suite code the same across versions?

I tend to agree. 2.6 and 3.0 decimal already differ plenty.

> There should probably be a PEP sets clearer guidelines about what should be backported from Py3.0.

Can you volunteer a draft? It could be PEP 3003. I'm probably too
close to 3.0 to be able to objectively write this, which really
represents end users' desire for stability in 2.6.

> Perhaps something like this:
> * If there is a new feature that can be implemented in both and will make both more attractive, then it should be in both.
> * If something is going away or changing in 3.0, then the 2.6 conversion tool mode should warn about it if possible.
> * If neither of the above apply, then leave 2.6 alone.
>
> > 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."
>
> Unless I misread what you're trying to do, that is a gratuitous API build-out (whether talking about Py2.6 or Py3.0) which adds a
> second-way-to-do-it to a module that already has a huge number of methods.  Our goal is to keep that module as a minimal
> implementation of the spec.  Fattening the API will make the module harder to use, not simpler.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)