[Python-Dev] Rounding Decimals

[Raymond Hettinger]

[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?

There should probably be a PEP sets clearer guidelines about what should be backported from Py3.0.  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.


Raymond