Changes by Catalin Iacob iacobcata...@gmail.com:
--
nosy: +catalin.iacob
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
___
Jim Jewett jimjjew...@gmail.com added the comment:
I like Nick Coghlan's suggestion in msg140493, but I think he was giving up too
soon in the or cases, and I think the confusion could be slightly reduced by
some re-spellings around return values and comments about short-circuiting.
def
Nick Coghlan ncogh...@gmail.com added the comment:
Changed stage and resolution to reflect the fact that none of the existing
patches adequately address the problem.
--
resolution: fixed -
stage: committed/rejected - needs patch
___
Python tracker
Nick Coghlan ncogh...@gmail.com added the comment:
NotImplemented is a speed and maintainability hack - the runtime cost and
additional code complexity involved in doing the same operator signalling via
exceptions would be prohibitive (check Objects/abstract.c in the CPython source
if you
Nick Coghlan ncogh...@gmail.com added the comment:
Also, a note regarding efficiency: as it calls the underlying methods directly
and avoids recursing through the full operand coercion machinery, I would
actually expect this approach to run faster than the current implementation.
--
Francesco Ricciardi francescor2...@yahoo.it added the comment:
On the one hand, it's not just a matter of total_ordering and rich comparison
operators, because all user defined operators may return NotImplemented when
they get types that they don't know how to handle.
On the other hand, if
Francesco Ricciardi francescor2...@yahoo.it added the comment:
I think the whole issue is indeed how NotImplemented is treated. To me saying
that 'not NotImplemented' is True is wrong. About the stack overflow I found
there are various possible fixes, however none will nice.
By definition,
Lennart Regebro rege...@gmail.com added the comment:
I was also surprised by the special return value, but it seems a bit overkill
to change the implementation of rich comparison operators just because it's
tricky to make a short and pretty class decorator that extends some operators
to all
Lennart Regebro rege...@gmail.com added the comment:
We *do* care about NotImplemented, that's the whole point of this bug report. I
don't see how this is a problem in the new_total_ordering.py example. Can you
give an example of when you get a stack overflow?
The examples in
Lennart Regebro rege...@gmail.com added the comment:
I'm attaching a file with the example classes returning NotImplemented, and a
different implementation of a total ordering, as an example of how returning
NotImplemented by one class will give the chance to the other class. This is
the
Alexander Boyd a...@opengroove.org added the comment:
I've attached a file demonstrating the stack overflow. It assumes
total_ordering has been defined as per new_total_ordering.py.
--
Added file: http://bugs.python.org/file21712/new_total_ordering_overflow.py
Lennart Regebro rege...@gmail.com added the comment:
Ah! I see how you mean. The problem isn't just if you turn the conversion
around from self other to other self. The problem in fact appears when a
rich text function uses the != operators on self directly.
I tried a version which uses the
Alexander Boyd a...@opengroove.org added the comment:
That's my point. My version, sane_total_ordering.py, fixes this by using
traditional functions and explicit NotImplemented checks.
--
___
Python tracker rep...@bugs.python.org
Lennart Regebro rege...@gmail.com added the comment:
Yeah, I can't say it's pretty though. :) Anyway this is an issue for 3.2 and
2.7 as well, then, so I add them back.
--
versions: +Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
Alexander Boyd a...@opengroove.org added the comment:
Ok. Yeah, I won't argue that it's pretty :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
Alexander Boyd a...@opengroove.org added the comment:
This is not fixed. The accepted fix doesn't take NotImplemented into account,
with the result that comparing two mutually-incomparable objects whose ordering
operations were generated with total_ordering causes a stack overflow instead
of
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
I'm not sure that we really care about handling NotImplemented (practicality
beats purity). At some point, if someone writing a class wants complete
control over the rich comparison methods, then they're going to have to write
Alexander Boyd a...@opengroove.org added the comment:
But it seems pointless to force someone to implement all of the rich comparison
methods when they may want to do something as simple as this:
class Foo:
...
def __lt__(self, other):
if not isinstance(other, Foo):
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
It may seem pointless, but it takes less than a minute to do it and it would be
both faster and clearer to do it manually. There's a limit to how much
implicit code generation can or should be done automatically.
Also, I'm
Alexander Boyd a...@opengroove.org added the comment:
Ok. I did write that against Python 2, so I wasn't aware of __eq__ and __ne__.
I'll keep that in mind.
I am curious, however, as to how this could break existing code. It seems like
code that relies on a stack overflow is already broken as
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
I am curious, however, as to how this could break existing code.
It seems like code that relies on a stack overflow is already
broken as it is.
Probably so. I worry about changes in semantics but it might be harmless.
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Éric, would you like to apply this to 2.7?
--
assignee: rhettinger - eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
Roundup Robot devnull@devnull added the comment:
New changeset 94c158199277 by Éric Araujo in branch '2.7':
Fix the total_ordering decorator to handle cross-type comparisons
http://hg.python.org/cpython/rev/94c158199277
--
nosy: +python-dev
stage: - committed/rejected
status: open -
Éric Araujo mer...@netwok.org added the comment:
FWIW, I just tested svnmerging the revision, the patch applied with minor merge
conflicts and the test suite passes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
type: crash - behavior
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
Lennart Regebro rege...@gmail.com added the comment:
This also affects Python 2.7, where it hasn't been fixed. Maybe reopen it?
--
nosy: +lregebro
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
Changes by Éric Araujo mer...@netwok.org:
--
status: closed - open
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Thanks for the report and patch.
Fixed. rSee 87853.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
Removed message: http://bugs.python.org/msg125757
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Thanks for the report and patch.
Fixed. See r87853.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
___
Python-bugs-list
New submission from Francesco Ricciardi francesco.riccia...@hp.com:
Tested with version 3.2a2. Not tested on version 2.7.
The current implementation of functools.total_ordering generates a stack
overflow because it implements the new comparison functions with inline
operator, which the Python
Francesco Ricciardi francesco.riccia...@hp.com added the comment:
Attached there is a solution of the problem, by implementing each comparison
only with the class __xx__ and __eq__ operators.
Also in the file there is a complete test suite for it.
--
Added file:
Changes by Benjamin Peterson benja...@python.org:
--
assignee: - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Thanks, this is a good idea.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10042
___
36 matches
Mail list logo
