<br><br><div><span class="gmail_quote">On 5/18/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;">
> Positional support is deprecated; there will only be support for a<br>> single argument. Read<br>> PEP 352 to see how BaseException will end up in Python 3000.<br><br>i don't see how BaseException addresses issues like accessing
<br>attributes rather than positional args, or introducing something equivalent<br>to ArgumentError. raising a TypeError is just semantically wrong in that<br>case -- it has nothing to do with types whatsoever.</blockquote>
<div><br><br>It doesn't address any of that. It isn't meant to. BaseException is the base exception and is not meant to support the kitchen sink.<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;">
from the pep:<br>> This PEP proposes introducing a new exception named BaseException<br>> that is a new-style class and has a single attribute, message (that will<br>> cause the deprecation of the existing args attribute)
</blockquote><div><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;">well, how do you suggest passing back the error-code, or file name of
<br>exceptions like IOError, or the attribute name of an AttributeError?<br>a single argument can only be used for pretty printing, not really providing<br>information *about* the exception. so unless people would want to
<br>use regular expressions to *parse* the message, why not allow keyword<br>arguments for extra info about the exception?</blockquote><div><br><br>Subclassing. You can override the constructor and do what you want.<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;">> And I brought this up with Guido once and he was not enthusiastic<br>> about it. Basically, keep exceptions simple. They are important
<br>> and basic enough to keep it simple. If you want fancier support,<br>> subclass Exception and add the support you want.</blockquote><div><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;">
well, if guido pronounced on it than i guess it's settled, but why do you<br>condsider *args to be simple and **kwargs not as simple? don't you<br>think "ex.filename" is simpler/clearer than "ex[1]"?</blockquote>
<div><br><br>I do. I am in no way suggesting that positional arguments are better. As I said, positional arguments are not going to be supported in Python 3000. The positional argument support is for backards-compatibility; that's why BaseException will end up having the constructor defined as::
<br><pre class="literal-block"> def __init__(self, message=''):<br> """Set the 'message' attribute'"""<br> self.message = message</pre><br>as specified in the PEP. But that does not stop someone from overriding BaseException in a subclass, as some built-ins do already. So you can easily add your filename attribute.::
<br><br> def __init__(self, filename):<br> self.filename = filename<br> BaseException.__init__(self, "%s does not exist" % filename)<br> <br>This also allows you to come up with an informative message if you so desire that is more standardized and based on some other argument.
<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;">-tomer<br><br>On 5/17/06, Brett Cannon <<a href="mailto:brett@python.org">
brett@python.org</a>> wrote:<br>><br>><br>><br>> On 5/17/06, tomer filiba <<a href="mailto:tomerfiliba@gmail.com">tomerfiliba@gmail.com</a>> wrote:<br>> > 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.<br>><br>><br>><br>> Positional support is deprecated; there will only be support for a single
<br>> 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.<br>> Basically, keep exceptions simple. They are important and basic enough to
<br>> keep it simple. If you want fancier support, subclass Exception and add the<br>> support you want.<br>><br>> -Brett<br>><br>> ><br>> 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<br>> 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:<br>> <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>><br>><br></blockquote></div><br>