On 2015-03-06 10:32, Volker Braun wrote:
Though that is perhaps not particularly good Python 3 - style. To me,
the idea is
* Implement __lt__ and __eq__ to make objects sortable
* Add @functools.total_order if (and only if) that defines a total order
* And/Or write your own decorator for diffe
Though that is perhaps not particularly good Python 3 - style. To me, the
idea is
* Implement __lt__ and __eq__ to make objects sortable
* Add @functools.total_order if (and only if) that defines a total order
* And/Or write your own decorator for different types of order
It might be worthwhi
On 2015-03-06 08:32, Vincent Delecroix wrote:
__cmp__ is gone in Python 3 see [1]. The way to implement comparisons
wil be through the various __lt__, __eq__, etc. There is already a
ticket opened for dealing with that in #16537. It would be better to
think about a solution that takes this into a
__cmp__ is gone in Python 3 see [1]. The way to implement comparisons
wil be through the various __lt__, __eq__, etc. There is already a
ticket opened for dealing with that in #16537. It would be better to
think about a solution that takes this into account. I do not know the
Cython way.
There is
On 2015-03-04 22:37, Travis Scrimshaw wrote:
Would it also be possible to check if (python) rich comparisons are
implemented and use those first before falling back to _cmp_, or having
the default try to call the rich comparisons?
Possible: maybe. But checking for Python-level stuff in Cython
Would it also be possible to check if (python) rich comparisons are
implemented and use those first before falling back to _cmp_, or having the
default try to call the rich comparisons? I remember implementing the rich
comparisons but then I ran cmp(x, y) with the instances of this class x,y
On Wednesday, March 4, 2015 at 5:47:59 AM UTC-8, Simon King wrote:
>
> But wouldn't we still have the complication for Cython classes, that one
> has to actually *copy* code from sage.structure.element.Element? If I
> recall correctly, this is needed in order to create hashable elements
> (if yo
Simon King wrote:
> According to the documentation, one is allowed to treat __richcmp__
> separate from __cmp__. Hence, it is legal to have separate behaviour
> for <,<= etc and for cmp(,).
>
> Is that possibility used in Sage somewhere?
Yes, see src/sage/rings/real_mpfi.pyx.
--
Marc
--
You r
On 2015-03-04 16:34, Simon King wrote:
one should perhaps rather support _richcmp_ and _cmp_,
where the default __richcmp__ tries to call _richcmp_ after coercion and
falls back to _cmp_ if it fails.
That's exactly how things are currently done (except there is also some
_richcmp_c_impl and _cmp
Hi Jeroen,
On 2015-03-04, Jeroen Demeyer wrote:
> Anyway, continuing the above example:
> sage: E += E
> we got coercion
>
> The fact that __iadd__ calls _add_ would be analogous to __richcmp__
> calling _cmp_ instead of __cmp__. And that is what I want to do.
According to the documentation, on
On 2015-03-04 15:18, Simon King wrote:
No. If a Python class has just *some* __add__, then the coercion framework
is out of the game. It must be sage.structure.element.ModuleElement.__add__,
or it won't work. Example:
sage: from sage.structure.element import ModuleElement
sage: class MyClass
Hi Jeroen,
On 2015-03-04, Jeroen Demeyer wrote:
> On 2015-03-04 14:47, Simon King wrote:
>> I don't agree with that description. If a Python class has both __cmp__
>> and _cmp_ (or both __add__ and _add_), then of course __cmp__ (resp.
>> __add__) are called.
>
> If a Python class has __add__ and
On 2015-03-04 14:47, Simon King wrote:
I don't agree with that description. If a Python class has both __cmp__
and _cmp_ (or both __add__ and _add_), then of course __cmp__ (resp.
__add__) are called.
If a Python class has __add__ and _add_, then the *coercion framework*
will use _add_, not __
Hi Jeroen,
On 2015-03-04, Jeroen Demeyer wrote:
> On 2015-03-04 14:14, Simon King wrote:
>> "Priority" in the sense of "if you want to implement comparison for
>> elements, then implement "_cmp_" rather than "__cmp__"?
> Yes. In other words: if a Python class has both __cmp__ and _cmp_, the
> co
On 2015-03-04 14:14, Simon King wrote:
"Priority" in the sense of "if you want to implement comparison for
elements, then implement "_cmp_" rather than "__cmp__"?
Yes. In other words: if a Python class has both __cmp__ and _cmp_, the
coercion framework should call _cmp_ (which will default to __
Hi Jeroen,
On 2015-03-04, Jeroen Demeyer wrote:
> In #17890, I want to rename _cmp_c_impl to _cmp_ and make it cpdef (like
> the other arithmetic functions such as _add_). Then I also would like to
> reverse the convention and make _cmp_ take priority over __cmp__.
"Priority" in the sense of "
16 matches
Mail list logo
