<br><br><div><span class="gmail_quote">On 5/17/06, <b class="gmail_sendername">tomer filiba</b> <<a href="mailto:tomerfiliba@gmail.com">tomerfiliba@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
hi all<br><br>i would like to suggest changing the base-exception class, whatever<br>it may be (Exception/BaseException) to work with keyword arguments<br>instead of positional ones.</blockquote><div><br><br>Positional support is deprecated; there will only be support for a single argument. Read PEP 352 to see how BaseException will end up in Python 3000.
<br><br>And I brought this up with Guido once and he was not enthusiastic about it. Basically, keep exceptions simple. They are important and basic enough to keep it simple. If you want fancier support, subclass Exception and add the support you want.
<br><br>-Brett<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">instead of<br><br>try:<br> ...<br>except IOError, ex:<br> print ex[1]
<br># or<br>except IOError, (code, text, filename):<br> ...<br> # which means changes to code/text/filename do not change<br> # the exception object<br><br>use<br><br>try:<br> raise IOError(filename = "lala", code=17, text="blah blah blah")
<br>except IOError, ex:<br> ex.code = 18<br> raise<br><br>raise IndexError("invalid index", index = the_index)<br>raise KeyError("key not found", key = the_key)<br>raise AttributeError("attribute not found", name = name)
<br><br>where the new exception can be something like<br><br>class Exception:<br> def __init__(self, message = None, **kw):<br> self._message = message<br> self.__dict__.update(kw)<br> def __repr__(self):
<br> attrs = sorted("%s = %r" % (k, v)<br> for k, v in self.__dict__.iteritems()<br> if not k.startswith("_"))<br> return "<%s(%s, %s)>" % (self.__class__.__name__,
<br> self._message, ", ".join(attrs))<br><br>class IOError(Exception):<br> pass<br><br>raise IOError(code = 17, text = "EBLAH", filename = "lalala")<br><br>the builtin errors might want to enforce an "exception signature",
<br><br>class ExceptionSignature(Exception):<br> attributes = []<br> def __init__(self, *args, **kw):<br> for name in self.attributes:<br> assert name in kw, "expected an attribute named %s" % (name,)
<br> Exception.__init__(self, *args, **kw)<br><br>class IOError(ExceptionSignature):<br> attributes = ["code", "text", "filename"]<br><br>or something like that, so the attributes of the exception are part
<br>of its official interface.<br><br>rationale:<br>* today, AttributeError's are raised as<br>AttributeError("%s object has no attribute %s" % ...)<br>which means analyzing the exception requires parsing text!<br>
* IOError (among others), for instance, does nasty and not-so-well documented<br>overloading of named/positional arguments: when you pass 1-3 arguments,<br>they are stored in .args, but also in .errno, .strerror, and<br>
.filename. if you pass<br>more than 3 arguments, the attributes are all set to None and only<br>.args is filled.<br>yuck.<br><br>you can see this for reference:<br><a href="http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496698">
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496698</a><br><br>----<br><br>that said, i would also want to introduce ArgumentError. there are<br>many times just a ValueError isn't enough. instead, having a builtin
<br>ArgumentError would made things more clear:<br><br>def write_to_file(the_file):<br> if the_file.closed:<br> raise ArgumentError("the file must be open", name = "the_file")<br> the_file.write(...)
<br><br>and with ArgumentError included, calling functions with invalid<br>signatures would also raise ArgumentError. TypeError is quite<br>silly in this case, as it has nothing to do with the *type* of<br>the function or its arguments.
<br><br>>>> def f(a): pass<br>>>> f(1,2)<br>Traceback (most recent call last):<br> File "<stdin>", line 1, in ?<br>*TypeError*: f() takes exactly 1 argument (2 given)<br>>>> type(f)
<br><type 'function'> # like any other function<br><br>TypeError is too-broadly overloaded this way.<br><br><br>-tomer<br>_______________________________________________<br>Python-3000 mailing list<br><a href="mailto:Python-3000@python.org">
Python-3000@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/python-3000">http://mail.python.org/mailman/listinfo/python-3000</a><br>Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/brett%40python.org">
http://mail.python.org/mailman/options/python-3000/brett%40python.org</a><br></blockquote></div><br>