[Python-Dev] str(Exception) changed, is that intended?
I know that my unittests should not rely on this, but is this change intended? c:\sf\ctypes_headpy24 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) 'exceptions.Exception' ^Z c:\sf\ctypes_headpy Python 2.5a0 (trunk:42903M, Mar 7 2006, 22:01:07) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) class 'exceptions.Exception' ^Z ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(Exception) changed, is that intended?
On 3/7/06, Thomas Heller [EMAIL PROTECTED] wrote: I know that my unittests should not rely on this, but is this change intended? c:\sf\ctypes_headpy24 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) 'exceptions.Exception' ^Z c:\sf\ctypes_headpy Python 2.5a0 (trunk:42903M, Mar 7 2006, 22:01:07) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) class 'exceptions.Exception' ^Z It's a side-effect of making built-in exceptions new-style classes. Not sure how you would override the string representation of a class anyway to fix this. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(Exception) changed, is that intended?
On 3/7/06, Brett Cannon [EMAIL PROTECTED] wrote: On 3/7/06, Thomas Heller [EMAIL PROTECTED] wrote: I know that my unittests should not rely on this, but is this change intended? c:\sf\ctypes_headpy24 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) 'exceptions.Exception' ^Z c:\sf\ctypes_headpy Python 2.5a0 (trunk:42903M, Mar 7 2006, 22:01:07) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) class 'exceptions.Exception' ^Z It's a side-effect of making built-in exceptions new-style classes. Not sure how you would override the string representation of a class anyway to fix this. IMO it shouldn't be fixed. Classic classes define their str to print the module name and class name with a dot in between; new-style classes use the same format as their repr. Making exceptions new-style classes is going to break a number of things; that's just inevitable. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(Exception) changed, is that intended?
On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote: IMO it shouldn't be fixed. Classic classes define their str to print the module name and class name with a dot in between; new-style classes use the same format as their repr. Making exceptions new-style classes is going to break a number of things; that's just inevitable. What else do you expect to break? Should we at least try to describe expected breakage in PEP 352? -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(Exception) changed, is that intended?
On 3/7/06, Barry Warsaw [EMAIL PROTECTED] wrote: On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote: IMO it shouldn't be fixed. Classic classes define their str to print the module name and class name with a dot in between; new-style classes use the same format as their repr. Making exceptions new-style classes is going to break a number of things; that's just inevitable. What else do you expect to break? Should we at least try to describe expected breakage in PEP 352? Anything that depends on the differences in behavior between classic and new-style classes, e.g. multiple inheritance if the inheritance graph contains a diamond, or type(exc) having a specific value (namely, the metaclass for classic classes), or certain broken behaviors (like read-only properties not being really read-only). It's hard to make a complete list. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str(Exception) changed, is that intended?
On 3/7/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 3/7/06, Barry Warsaw [EMAIL PROTECTED] wrote: On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote: IMO it shouldn't be fixed. Classic classes define their str to print the module name and class name with a dot in between; new-style classes use the same format as their repr. Making exceptions new-style classes is going to break a number of things; that's just inevitable. What else do you expect to break? Should we at least try to describe expected breakage in PEP 352? Anything that depends on the differences in behavior between classic and new-style classes, e.g. multiple inheritance if the inheritance graph contains a diamond, or type(exc) having a specific value (namely, the metaclass for classic classes), or certain broken behaviors (like read-only properties not being really read-only). It's hard to make a complete list. Right, stuff dealing with the type could break. Instance-related stuff dealing with the interface will continue to work as expected and be fully backwards-compatible (unless someone complains about now having a proper __unicode__ method, in which case it will definitely go in one ear and out the other for me). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com