On 10/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 10/28/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Brett Cannon wrote: > > > Anyway, as soon as the cron job posts the PEP to the web site (already > > > checked into the new svn repository) have a read and start expounding > > > about how wonderful it is and that there is no qualms with it > > > whatsoever. =) > > > > You mean aside from the implementation of __getitem__ being broken in > > BaseException*? ;) > > Are you clairvoyant?! The cronjob wass broken due to the SVN > transition and the file wasn't on the site yet. (Now fixed BTW.) Oh, > and here's the URL just in case: > http://www.python.org/peps/pep-0352.html >
Nick got the python-checkins email and then read the PEP from the repository (or at least that is what I assume since that is how Neal managed to catch the PEP literally in under 5 minutes after checkin). > > Aside from that, I actually do have one real problem and one observation. > > > > The problem: The value of ex.args > > > > The PEP as written significantly changes the semantics of ex.args - > > instead > > of being an empty tuple when no arguments are provided, it is instead a > > singleton tuple containing the empty string. > > > > A backwards compatible definition of BaseException.__init__ would be: > > > > def __init__(self, *args): > > self.args = args > > self.message = '' if not args else args[0] > > But does anyone care? As long as args exists and is a tuple, does it > matter that it doesn't match the argument list when the latter was > empty? IMO the protocol mostly says that ex.args exists and is a tuple > -- the values in there can't be relied upon in pre-2.5-Python. > Exceptions that have specific information should store it in a > different place, not in ex.args. > Looking at http://docs.python.org/lib/module-exceptions.html , it looks like Guido is right. All it ever says is that it is a tuple and that any passed-in arguments go into 'args'; nothing about its default value if no arguments are passed in. But I personally have no qualms changing it if people want it, so -0 from me on making it more backwards-compatible. > > The observation: The value of ex.message > > > > Under PEP 352 the concept of allowing "return x" to be used in a > > generator > > to mean "raise StopIteration(x)" would actually align quite well. A bare > > "return", however, would need to be changed to translate to "raise > > StopIteration(None)" rather than its current "raise StopIteration" in order > > to > > get the correct value (None) into ex.message. > > Since ex.message is new, how can you say that it should have the value > None? IMO the whole idea is that ex.message should always be a string > going forward (although I'm not going to add a typecheck to enforce > this). > My feeling exactly on 'message'. -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
