pdb and jump - newbie question
I have been trying to figure out how to use pdb to correct simple errors in a file and then continue with program execution. Perhaps someone can tell me why this is not working for me. Here is my file test.py: #-- import pdb pdb.set_trace() print """ this is a test file """ x = 0 y = 4.2 z = y/x print z print "with a bug" #-- The line `z = y/x` fails because x is zero. If I run this, I can step until that exception occurs, at which point I see ZeroDivisionError: 'float division' > c:\temp\test.py(9)() -> z = y/x (Pdb) Now, I thought I would be able to set x to another value and then jump back to re-run the line with the division statement. However, that does not seem to work. Here's what happens: (Pdb) !x = 2 (Pdb) j 9 > c:\temp\test.py(9)() -> z = y/x (Pdb) n --Return-- > c:\temp\test.py(9)()->None -> z = y/x (Pdb) n Traceback (most recent call last): File "C:\temp\test.py", line 9, in z = y/x ZeroDivisionError: float division I have also tried assigning a value to z and jumping past the illegal division, but I can't get that to work either. It seems that there must be a way to do this, but I can't find it. Any help would be appreciated. -- http://mail.python.org/mailman/listinfo/python-list
subclassing complex
I have been trying to subclass complex, but I am not able to get the right-hand arithmetic operators working. As shown below, if an object of my subclass 'xcomplex' is added on the right of a 'comlex' object, the type returned is 'complex', not 'xcomplex'. I've tried subclassing float and it works fine (don't even need to define __coerce__ in that case) Is this a bug, or am I missing something? Here's an example: class xcomplex( complex ): def __new__(cls,*args,**kwargs): return complex.__new__(cls,*args,**kwargs) def __coerce__(self,other): t = complex.__coerce__(self,other) try: return (self,xcomplex(t[1])) except TypeError: return t def __add__(self,x): return xcomplex( complex.__add__(self,x) ) def __radd__(self,x): return xcomplex( complex.__radd__(self,x) ) xz = xcomplex(1+2j) xy = float(10.0) z = complex(10+1j) print type(xz + z) # OK: get xcomplex print type(xz + xy) # OK: get xcomplex print type(xz + 10) # OK: get xcomplex print type(xy + xz) # OK: get xcomplex print type(10 + xz) # OK: get xcomplex print type(z + xz) # fails: get complex -- http://mail.python.org/mailman/listinfo/python-list
Re: subclassing complex
On Aug 30, 6:18 am, Patrick Maupin <[EMAIL PROTECTED]> wrote: > On Aug 29, 4:24 am, Peter Otten <[EMAIL PROTECTED]> wrote: > > > > > A minimal example is > > > >>> class Complex(complex): > > > ... def __radd__(self, other): print "radd" > > ...>>> 1j + Complex() > > > 1j > > > versus > > > >>> class Int(int): > > > ... def __radd__(self, other): print "radd" > > ...>>> 1 + Int() > > > radd > > > I think the complex subclass should behave like the int subclass. > > To get an authoritative answer you should file a bug report. > > Hmm, good point. I shouldn't look at newsgroups when I'm too tired to > see the whole problem. > > According to the documentation > athttp://docs.python.org/ref/numeric-types.html: > > "Note: If the right operand's type is a subclass of the left operand's > type and that subclass provides the reflected method for the > operation, this method will be called before the left operand's non- > reflected method. This behavior allows subclasses to override their > ancestors' operations." > > I think this makes it pretty clear that the OP found a bug in how > complex works. (Before I read this note, I would have assumed that > the int() handling was broken, but it looks like a supportable design > decision. Probably whoever implemented it wasn't even thinking about > complex numbers, but for consistency, I would think they should be > made to work the same.) > > Regards, > Pat Thanks for the comments. I have filed it as an issue. Regards Blair -- http://mail.python.org/mailman/listinfo/python-list
