Mark Dickinson dicki...@gmail.com added the comment:
In my opinion, 2.6.6 was faulty in the float + xint case, for the same
reasons as above, and 2.7 is faulty in both float + xint and complex +
xint.
Well, I disagree: Python is behaving as designed and documented in these
cases. If you
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file19832/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5211
___
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file19828/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5211
___
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file19820/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5211
___
Blair bidih...@gmail.com added the comment:
Just to keep this discussion as clear as possible Mark, it was your first
option that I suggest is needed.
When that is done (as it was for a subclass of float in 2.6.6) it is
possible for the author of the subclass to implement commutative binary
Mark Dickinson dicki...@gmail.com added the comment:
Just to keep this discussion as clear as possible Mark, it was your
first option that I suggest is needed.
Okay, so you want float instance + xint instance to try xint.__radd__
before float.__add__.
How do you propose this be achieved?
Changes by Mark Dickinson dicki...@gmail.com:
Removed file: http://bugs.python.org/file19859/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5211
___
Blair bidih...@gmail.com added the comment:
I am not really the person (I don't know how Python is implemented) to
explain how the correct behaviour should be achieved (sorry). I do
appreciate that this may seem like exceptional behaviour. Numbers are a bit
different.
However, for what its
Mark Dickinson dicki...@gmail.com added the comment:
I think that's expected behaviour. Note that int vs float behaves in the same
way as float vs complex:
class xint(int):
... def __radd__(self, other):
... print __radd__
... return 42
...
3 + xint(5)
__radd__
42
3.0
Blair bidih...@gmail.com added the comment:
I see your point Mark, however it does not seem to be the right way to do
this.
Are you aware that Python has formally specified this behaviour somewhere? I
could not find an explicit reference in the documentation.
The problem that has been fixed is
Blair bidih...@gmail.com added the comment:
I'd like to add a few more observations to the mix.
I have run the following in both 2.6.6 and in 2.7
class xfloat(float):
def __new__(cls,x):
return float.__new__(cls,x)
def __radd__(self,lhs):
print __radd__ got: %s %
Blair bidih...@gmail.com added the comment:
Hi Mark,
I thought that this had all been fixed, but it seems not.
Consider the following:
class xcomplex( complex ):
def __new__(cls,*args,**kwargs):
return complex.__new__(cls,*args,**kwargs)
def __add__(self,x):
return
Mark Dickinson dicki...@gmail.com added the comment:
r78280 didn't remove the implicit coercion for rich comparisons; that's now
been done in r81606.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5211
Mark Dickinson dicki...@gmail.com added the comment:
Apologies for the delay; tomorrow was a long time coming...
The patch looks great---thank you! I added a .. versionchanged note to the
documentation, and fixed a couple of whitespace issues; apart from that I
didn't change anything.
Meador Inge mead...@gmail.com added the comment:
I added a .. versionchanged note to the documentation, and fixed a
couple of whitespace issues;
Thanks. I checked out the changes you made so that I will know what to do next
time :).
Fixed now, with apologies to Meador.
No worries.
Meador Inge mead...@gmail.com added the comment:
if complex were made 'new-style' in 2.7, then it *would* be possible to
write fairly obvious code (not using coerce or __coerce__) that operated in
the same way in both 2.7 and 3.2. So I still think it's worth
considering.
Agreed. I
Mark Dickinson dicki...@gmail.com added the comment:
Thanks. I'll try to find time to look at this tomorrow.
--
assignee: - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5211
Mark Dickinson dicki...@gmail.com added the comment:
Blair: I don't think you'll have any problems getting the behaviour you in
Python 3. For example:
Python 3.2a0 (py3k:77952, Feb 4 2010, 10:56:12)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type help, copyright, credits or
Mark Dickinson dicki...@gmail.com added the comment:
As you pointed out in issue 3734, the patch is basically:
snipped patch that adds Py_TPFLAGS_CHECKTYPES
Yes, that's the essence of it. In addition, each of the functions implementing
a complex special method would need to do its own
Mark Dickinson dicki...@gmail.com added the comment:
Yes, that was what I was proposing. But as you point out, the new
behaviour wouldn't even match the behaviour of Python 3.x, so it really
wouldn't be a terribly useful change.
Hmm. I take this back: if complex were made 'new-style' in
Mark Dickinson dicki...@gmail.com added the comment:
Yes, I'd certainly be interested in reviewing a patch. Though the current
behaviour is at most a minor wart, and since it's gone in Python 3.x the
motivation to fix it isn't huge. :)
Where as I think gumtree wants the xcomplex case to
Blair bidih...@gmail.com added the comment:
I also agree that this bug was never more than a small wart. However, I'm now
curious.
If Python 3 does not support coercion, I think that it will not be possible to
write something like my xfloat class, derived from float (i.e., some binary
Meador Inge mead...@gmail.com added the comment:
Mark
Yes, that was what I was proposing.
As you pointed out in issue 3734, the patch is basically:
===
--- Objects/complexobject.c (revision 77909)
+++
Blair bidih...@gmail.com added the comment:
OK. I have gone back to the beginning to refresh my memory and I see a possible
point of misunderstanding. I am not sure that we are really talking about the
problem that prompted my initial report (msg72169, issue 3734).
Immediately following my
Meador Inge mead...@gmail.com added the comment:
Mark,
Is this still of interest?
I found the relevant changes in py3k, but I am not sure it is the behavior that
gumtree is expecting. Since py3k removes coercion completely, the test case
from issue 3734 would just issue:
Traceback (most
Mark Dickinson dicki...@gmail.com added the comment:
Comment by gumtree copied from issue3734 discussion:
While Mark Dickinson's patch fixes the documentation, it does not
offer
a solution to the original problem, which was rooted in a need to
provide special behaviour based on the
Blair bidih...@gmail.com added the comment:
I am happy to collaborate in finding a solution, but I do not have
enough knowledge or skill to work with the code alone.
Simply documenting it does not remove the frustration that a few people
will enounter. The key point being that you can
New submission from Mark Dickinson dicki...@gmail.com:
In the 'coercion rules' section of the reference manual, at:
http://docs.python.org/dev/reference/datamodel.html#id5
it says:
Over time, the type complex may be fixed to avoid coercion.
In 3.x, the complex type has (necessarily) been
28 matches
Mail list logo
