On Thu, Feb 19, 2004 at 06:32:53PM -0600, John Goerzen wrote: > On Thu, Feb 19, 2004 at 08:35:05PM +0000, Andrew Suffield wrote: > > The only way to get shorter is to not handle the errors - which is the > > norm in python. > > It's no different than Perl. Yes, precisely my point. What's yours? > Actually, Python's *default* error will be more useful that > most *coded* errors in Perl since Python includes not only the type of > error (in the form of the exception object), but also the errors > description, thread in which it occured (with a name, if the thread was > named), and full stack trace. Factually incorrect, because you get all that with perl too, and python's default error doesn't give you a meaningful description. See the Carp documentation. > Also, lots of code -- both Perl and C -- does not even check for errors > at all. It is extremely commonplace to see calls to write() that never > check for errors in C, or calls to printf or print or whatever your > output function is. In my book, that's worse. Vomiting to the screen is not better than aborting. And comparing the quality of broken code is silly. > There is no such thing as an I/O operation without an error check in > Python, and in my book, that is an incredibly Good Thing. There's a perl module that calls die "moo" on every IO error if that's what you really want, but nobody uses it because when they think about it, that is not what they want. They want a *useful* error message. Not an obtuse message suggesting that there might be some sort of error. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature