On Jan 14, 2008 5:48 AM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 1/12/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > > During the discussion about the new Rational implementation
> > > (http://bugs.python.org/issue1682)
On 1/12/08, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > During the discussion about the new Rational implementation
> > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > Decimal should not implement the n
On Jan 13, 2008 7:26 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> 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") b
On Jan 13, 2008 3:41 PM, Leif Walsh <[EMAIL PROTECTED]> wrote:
> 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 plan
On Jan 13, 2008 6:12 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 8:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > > During the discussion about the new Rational implementation
> > > (http://bugs
On Jan 12, 2008 8:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > During the discussion about the new Rational implementation
> > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > Decimal should not
On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> 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.o
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 mention
[Aahz]
> 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.
No doubt, the spec made a number of choices that are obvious only if you work
at IBM. And, there is no doubt, the module has
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
2008/1/7, Raymond Hettinger <[EMAIL PROTECTED]>:
> 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.
Question.
I'm so used to quantize that I don't care. And I'm, in general, -0 to
adding
[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 i
On Jan 6, 2008 10:51 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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
[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
[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
On Jan 6, 2008 7:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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 patc
[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
On Jan 6, 2008 7:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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 patc
[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
On Jan 6, 2008 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> 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
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 b
On Jan 6, 2008 1:21 AM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2008 7:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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 sa
On Jan 5, 2008 7:11 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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__() m
> 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?
24 matches
Mail list logo
