Hi Armin,
> On Wed, Dec 28, 2005 at 09:56:43PM +0100, M.-A. Lemburg wrote:
>>> d += 1.2
>>> d
NotImplemented
>> The PEP documenting the coercion logic has complete tables
>> for what should happen:
>
> Well, '+=' does not invoke coercion at all, with new-style classes like
> Decimal.
Hi Marc,
On Wed, Dec 28, 2005 at 09:56:43PM +0100, M.-A. Lemburg wrote:
> > d += 1.2
> > d
> >> NotImplemented
>
> The PEP documenting the coercion logic has complete tables
> for what should happen:
Well, '+=' does not invoke coercion at all, with new-style classes like
Decimal.
> Look
Armin Rigo wrote:
> Hi Facundo,
>
> On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
> d += 1.2
> d
>> NotImplemented
>
> The situation appears to be a mess. Some combinations of specific
> operators fail to convert NotImplemented to a TypeError, depending on
> old- or ne
Hi Facundo,
On Mon, Dec 26, 2005 at 02:31:10PM -0300, Facundo Batista wrote:
> > nb_add and nb_multiply should be tried. I don't think that this would
> > break existing C or Python code, but it should probably only go in 2.5,
> > together with the patch #1390657 that relies on it.
>
> It'd be g
2005/12/26, Armin Rigo <[EMAIL PROTECTED]>:
> Done in patch #1390657.
Fantastic, Armin, thank you!
> nb_add and nb_multiply should be tried. I don't think that this would
> break existing C or Python code, but it should probably only go in 2.5,
> together with the patch #1390657 that relies on
Hi,
On Mon, Dec 26, 2005 at 02:40:38AM +1000, Nick Coghlan wrote:
> That sounds like the right definition to me (I believe this behaviour is what
> Raymond and Facundo were aiming for with the last round of updates to
> Decimal).
Done in patch #1390657.
Although this patch passes all existing
Hi Brett,
On Sun, Dec 25, 2005 at 11:55:11AM -0800, Brett Cannon wrote:
> Maybe. Also realize we will have a chance to clean it up when Python
> 3 comes around since the classic class stuff will be ripped out. That
> way we might have a chance to streamline the code.
For once, old-style classes
Armin Rigo <[EMAIL PROTECTED]> wrote:
> Of course, speaking of a rewrite, PyPy does the "right thing" in
> these two areas. Won't happen to CPython, though. There are too
> much backward-compatibility issues with the PyTypeObject
> structure; I think we're doomed with patching the bugs as they
>
On 12/25/05, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Reinhold,
>
> On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote:
> > > that nobody fully understands the convoluted code paths of abstract.c
> > > any more :-(
> >
> > Time for a rewrite?
>
Maybe. Also realize we will have
Armin Rigo wrote:
> Hi Reinhold,
>
> On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote:
>>> that nobody fully understands the convoluted code paths of abstract.c
>>> any more :-(
>> Time for a rewrite?
>
> Of course, speaking of a rewrite, PyPy does the "right thing" in these
>
Hi Reinhold,
On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote:
> > that nobody fully understands the convoluted code paths of abstract.c
> > any more :-(
>
> Time for a rewrite?
Of course, speaking of a rewrite, PyPy does the "right thing" in these
two areas. Won't happen to
Armin Rigo wrote:
> Hi Facundo,
>
> On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
>> >>> d += 1.2
>> >>> d
>> NotImplemented
>
> The situation appears to be a mess. Some combinations of specific
> operators fail to convert NotImplemented to a TypeError, depending on
> old- or
Hi Facundo,
On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote:
> >>> d += 1.2
> >>> d
> NotImplemented
The situation appears to be a mess. Some combinations of specific
operators fail to convert NotImplemented to a TypeError, depending on
old- or new-style-class-ness, although this
13 matches
Mail list logo
