On Jan 5, 2008 7:11 PM, Raymond Hettinger wrote:

...

I think pep 3141's round(x, ndigits) does (1). The only thing it doesn't support yet is specifying the rounding mode. Perhaps the pep should say that round() passes any extra named arguments on to the __round__() method so that users can specify a rounding mode for types that support it?

That would clutter the interface. Just specify a universal rounding mode for __round__ and have Decimal's implementation of that method comply.

Yeah, thinking about this more, a .round() method on Context objects seems like a better way to handle the part of Mark's request that the round builtin doesn't cover. Of course, there may be even better alternatives that I haven't thought of. I'll post a patch to http://bugs.python.org/issue1623 tomorrow so we have something concrete to talk about. -- Namasté, Jeffrey Yasskin

FWIW, I don't think all of these patches are helpful. The implementations are so easy and the effects are so obvious, that it is simply better to decide what to do first, then do it afterwards. My own preference is to leave the decimal module alone (except for a __round__ method to be called by builtin.round). Adding more methods to that module does not make it easier to use -- there are already a mind-numbing range of choices in the current, minimal implementation of the spec. I would support having a separate module of convenience functions or a separate module that uses a subset, but growth of the core module will only make it harder to use and more difficult to maintain. Another idea for simplifcation is to write-up a good tutorial to the basics of using the module. Please show restraint when proposing API changes to decimal -- I think it would be easy to do more harm than good. Raymond ----- Original Message ----- From: "Jeffrey Yasskin" To: "Raymond Hettinger" Cc: "Mark Dickinson" ; "Python 3000" ; Sent: Sunday, January 06, 2008 3:26 PM Subject: Re: [Python-Dev] Rounding Decimals

On Jan 6, 2008 1:21 AM, Jeffrey Yasskin wrote:

...

On Jan 5, 2008 7:11 PM, Raymond Hettinger wrote:

...

...

I think pep 3141's round(x, ndigits) does (1). The only thing it doesn't support yet is specifying the rounding mode. Perhaps the pep should say that round() passes any extra named arguments on to the __round__() method so that users can specify a rounding mode for types that support it?

That would clutter the interface. Just specify a universal rounding mode for __round__ and have Decimal's implementation of that method comply.

Yeah, thinking about this more, a .round() method on Context objects seems like a better way to handle the part of Mark's request that the round builtin doesn't cover. Of course, there may be even better alternatives that I haven't thought of. I'll post a patch to http://bugs.python.org/issue1623 tomorrow so we have something concrete to talk about.

The new patch is posted: http://bugs.python.org/file9080/decimal-3141.patch I'll implement Context.round() in a separate patch. Comment away. :)

-- Namasté, Jeffrey Yasskin

[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

[Raymond]

...

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.

[Guido van Rossum]

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.

Yes. Will do. Raymond

[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. 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. 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. 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. Raymond

[Jeffrey Yasskin]

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.

Please recognize that our little system of patches and newsgroup discussions is easily overwhelmed by someone who is so prolific. Your work will not receive quality review and discussion if the volume blows beyond the bandwidth of the other participants.

...

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.

Arghh! You seem hell-bent on jamming this in. Please leave the decimal module alone. It does *not* need both a round() method and a quantize() method. I read Glyph's note and agree that it wasn't obvious how to round with the existing API. That is a documentation problem, not a call to add duplicate methods. When one of the module authors asks you to refrain for expanding the API, please pay special attention. In this case, you are working directly against a core philosophy for the design and maintenance of the module. I admire your enthusiasm, but please hold it in check. Raymond

On Mon, Jan 07, 2008, Raymond Hettinger wrote:

[Jeffrey Yasskin]

...

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.

Arghh! You seem hell-bent on jamming this in. Please leave the decimal module alone. It does *not* need both a round() method and a quantize() method.

I read Glyph's note and agree that it wasn't obvious how to round with the existing API. That is a documentation problem, not a call to add duplicate methods.

Excuse me. I have always thought that "quantize()" makes Decimal confusing in the context of the other mechanisms that Python makes available for other kinds of numbers. I have refrained from making an issue of it because I understand and (mostly) support the idea of keeping Decimal restricted to matching the decimal standard, but at this point, it seems that Tim Peters likes the idea, too. While I have a lot of respect for you, I think Uncle Timmy deserves some special respect, too.

When one of the module authors asks you to refrain for expanding the API, please pay special attention. In this case, you are working directly against a core philosophy for the design and maintenance of the module.

I'm not a current maintainer, but I was one of the instigators for the existence of Decimal. I understand that you're feeling frustrated about changes getting shoved in, but I don't think that discussion should be shut down because you have a particular point of view: the decimal module does not represent only your work. I suggest that the patches get dropped for the moment and the discussion rebooted. I haven't been following closely, but it seems that the main issue is that Python 3.0 is introducing a __round__() method. How do you think the decimal module should handle that? (Although I still like the idea of a .round() method for decimals, I think that round(Decimal()) is probably sufficient enough that I won't insist on it.) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

[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. Raymond

On Jan 12, 2008 5:09 PM, Jeffrey Yasskin wrote:

During the discussion about the new Rational implementation (http://bugs.python.org/issue1682), Guido and Raymond decided that Decimal should not implement the new Real ABC from PEP 3141. So I've closed http://bugs.python.org/issue1623 and won't be pursuing any of the extra rounding methods mentioned on this thread.

Well, I didn't really decide anything. I suggested that if the developers of Decimal preferred it, it might be better if Decimal did not implement the Real ABC, and Raymond said he indeed preferred it. Since this reduces the usefulness of numeric.Real, I'm somewhat disappointed in this outcome (as I imagine you are). However, Decimal has very little of my own sweat in it, and a lot of Raymond, Facundo (and others, including Mark), and the ABC thing is still somewhat experimental, so it wouldn't make sense for me to impose my ideas onto Decimal unilaterally, and I'm sure Raymond etc. have their reasons. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Jan 13, 2008 6:12 PM, Jeffrey Yasskin wrote:

On Jan 12, 2008 8:21 PM, Guido van Rossum wrote:

...

On Jan 12, 2008 5:09 PM, Jeffrey Yasskin wrote:

...

During the discussion about the new Rational implementation (http://bugs.python.org/issue1682), Guido and Raymond decided that Decimal should not implement the new Real ABC from PEP 3141. So I've closed http://bugs.python.org/issue1623 and won't be pursuing any of the extra rounding methods mentioned on this thread.

Well, I didn't really decide anything. I suggested that if the developers of Decimal preferred it, it might be better if Decimal did not implement the Real ABC, and Raymond said he indeed preferred it.

Since this reduces the usefulness of numeric.Real, I'm somewhat disappointed in this outcome (as I imagine you are). However, Decimal has very little of my own sweat in it, and a lot of Raymond, Facundo (and others, including Mark), and the ABC thing is still somewhat experimental, so it wouldn't make sense for me to impose my ideas onto Decimal unilaterally, and I'm sure Raymond etc. have their reasons.

Sorry for misrepresenting you. I am a little disappointed, but if we're right that numbers.Real is a good idea, then users will ask for Decimal to implement it, and the Decimal developers can change their minds in 3.1. Since I'm not one of those users, I'm not the right person to argue for this anyway. :)

I haven't been watching the python-dev list for very long, so maybe this has already been discussed ad nauseam (in which case, sorry), but, from the devil's advocate-ish mathematics side of things, unless numbers.Decimal is planned to be implemented with infinite precision (which I doubt, but could not confirm with an admittedly small amount of research), shouldn't it implement numbers.Rational instead? Was this ever discussed, or was it just assumed that numbers.Real was the right decision? Cheers, Leif

On Jan 13, 2008 7:26 PM, Jeffrey Yasskin wrote:

Guido mentioned the possibility briefly at http://mail.python.org/pipermail/python-3000/2007-April/007015.html ("One could argue that float and Decimal are <:Q, but I'm not sure if that makes things better pragmatically") but never really discussed as far as I can find (although I did think about it :).

Well, if nothing else, I'm certainly satisfied that my concerns about accuracy are being addressed. I will have to go read more of that discussion.

I prefer having float not implement Rational (Decimal's off the table) because developers usually think of them as approximations to arbitrary, possibly-irrational, real numbers, rather than as rational numbers with some odd constraints on their denominators. That is, to me, the ABCs a type implements are more about how developers should think about the type than the implementation of the type.

I see where you're coming from. My personal stance is that developers _shouldn't_ think that way, but I know that's an unpopular opinion, and isn't really worth discussion here.

[ A new thread is probably appropriate if anyone wants to discuss the philosophy, but I probably won't participate... ]

I don't feel any pressing need to continue this here and now. Thanks! -- Cheers, Leif

On Jan 14, 2008 5:48 AM, Jim Jewett wrote:

On 1/12/08, Guido van Rossum wrote:

...

On Jan 12, 2008 5:09 PM, Jeffrey Yasskin wrote:

...

During the discussion about the new Rational implementation (http://bugs.python.org/issue1682), Guido and Raymond decided that Decimal should not implement the new Real ABC from PEP 3141. So I've closed http://bugs.python.org/issue1623 and won't be pursuing any of the extra rounding methods mentioned on this thread.

...

Well, I didn't really decide anything. I suggested that if the developers of Decimal preferred it, it might be better if Decimal did not implement the Real ABC, and Raymond said he indeed preferred it.

I read his objections slightly differently.

He is very clear that Decimal itself should be restricted to the standard, and therefore should not natively implement the extensions.

Well, to me that sounds like idolizing the standard. The standard exists so as to ensure that decimal numbers have well-understood semantics that are implemented correctly. I don't think the standard was ever meant to exclude optimal interaction with the rest of a language. I'd like to see if ReXX implements numeric features over and above the standard.

But he also said that it might be reasonable for another package to subset or superset it in a friendlier way.

From a user's perspective, it might make more sense to move the strictly standard-conforming code into a module "decimal_standard" and make the friendlier-named "decimal" module be that friendly superset.

numbers.py is a different module, which must be explicitly imported.

If the objection is that

>>> decimal.Decimal("43.2").imag

would work (instead of throwing an exception) only when numbers.py has already been imported, then ... well, that confusion is inherent in the abstract classes.

Fortunately, the confusion is in your mind only, because that's not how ABCs work according to PEP 3119. While as a side effect of importing the numbers module, the Decimal class might become a virtual subclass of numbers.Real, that doesn't mean that implementation features are automatically added. The registration that might take place inside numbers.py *only* affects the outcome of isinstance() and issubclass() checks -- it doesn't magically add missing attributes or methods to the class.

Or is the problem that it *still* wouldn't work, without help from the decimal module itself?

Right.

In that case, 3rd party registration is fairly limited, and this might be a good candidate for trying to figure out ABCs and adapters *should* work together.

Of course 3rd party registration is limited -- there's no way that you could automatically define the right semantics, since the ABCs don't have a way to express semantics. PEP 3119 is meant as a *first step* towards adopting ABCs as a core feature. The changes added to collections.py and numbers.py are best considered as minimal examples. The main achievement of the PEP is probably the hooks that allow you to override isinstance() and issubclass(), plus the decision (which was discussed at length) to use ABCs (with virtual inheritance), not interfaces, to model similarities between class APIs. -- --Guido van Rossum (home page: http://www.python.org/~guido/)