People:
Pablo Hoffman opened this bug: "[1764761] Decimal comparison with None
fails in Windows".
It's not a Decimal problem, see the differente behaviour of this basic
test in Linux and Windows:
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu
4.1.2-0ubuntu4)] on linux2
>>> c
NonImplemented isn't treated as special when returned by __cmp__();
__cmp__ is not considered a binary operator like __add__. (__lt__ and
friends *do* get treated as such -- but instead of __rlt__ we use
__gt__, etc.)
--Guido
On 8/2/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> People:
>
> Pab
2007/8/2, Guido van Rossum <[EMAIL PROTECTED]>:
> NonImplemented isn't treated as special when returned by __cmp__();
> __cmp__ is not considered a binary operator like __add__. (__lt__ and
> friends *do* get treated as such -- but instead of __rlt__ we use
> __gt__, etc.)
I understand that is tr
On 02/08/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> I understand that is tricky how NotImplemented and comparisons interact.
>
> But how do you explain the difference in behaviour between Linux and Windows?
A wild guess: c < None falls back to checking c.__cmp__(None) < 0.
This translates to
Guido van Rossum schrieb:
> NonImplemented isn't treated as special when returned by __cmp__();
> __cmp__ is not considered a binary operator like __add__. (__lt__ and
> friends *do* get treated as such -- but instead of __rlt__ we use
> __gt__, etc.)
But if it's not treated as special, why doesn'
"Facundo Batista" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| >>> class C(object):
| ... def __cmp__(self, other):
| ... return NotImplemented
| ...
Given that you 'should' return an int, doing elsewise has undefined
results.
| >>> c = C()
| >>> print c < None
I
Facundo Batista schrieb:
> 2007/8/2, Guido van Rossum <[EMAIL PROTECTED]>:
>
>> NonImplemented isn't treated as special when returned by __cmp__();
>> __cmp__ is not considered a binary operator like __add__. (__lt__ and
>> friends *do* get treated as such -- but instead of __rlt__ we use
>> __gt_
2007/8/2, Paul Moore <[EMAIL PROTECTED]>:
> A wild guess: c < None falls back to checking c.__cmp__(None) < 0.
> This translates to NotImplemented < 0, and as the ordering of built in
> types is implementation dependent, maybe that explains the difference
> between Windows and Linux?
"NotImplemen
Terry Reedy schrieb:
> "Facundo Batista" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | >>> class C(object):
> | ... def __cmp__(self, other):
> | ... return NotImplemented
> | ...
>
> Given that you 'should' return an int, doing elsewise has undefined
> results.
2007/8/2, Terry Reedy <[EMAIL PROTECTED]>:
> Given that you 'should' return an int, doing elsewise has undefined
> results.
I'll fix decimal to always return sane values from __cmp__, :)
Thank you all!
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.
On 8/2/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Returning anything other than an int or NotImplemented raises an exception.
> NotImplemented seems to be special cased so that the other object's
> __cmp__ can be tried too.
Oops, sorry for the misinformation. :-(
--
--Guido van Rossum (home p
Martin,
Do you know why T_PYSSIZET is inside a #ifdef HAVE_LONG_LONG? That
seems like a mistake. Here's the code:
#ifdef HAVE_LONG_LONG
#define T_LONGLONG 17
#define T_ULONGLONG 18
#define T_PYSSIZET 19 /* Py_ssize_t */
#endif /* HAVE_LONG_LONG */
ISTM, that T_PYSSIZET should be
Neal Norwitz wrote:
> Martin,
>
> Do you know why T_PYSSIZET is inside a #ifdef HAVE_LONG_LONG? That
> seems like a mistake. Here's the code:
>
> #ifdef HAVE_LONG_LONG
> #define T_LONGLONG 17
> #define T_ULONGLONG 18
> #define T_PYSSIZET 19 /* Py_ssize_t */
> #endif /* HAVE_LONG_
13 matches
Mail list logo
