Brett Cannon wrote: > On 10/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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).
Actually, when you first check a PEP in, the diff includes the entire text of the PEP - so I just read the python-checkins email :) >> 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. I agree changing the behaviour is highly unlikely to cause any serious problems (mainly because anyone *caring* about the contents of args is rare), the current behaviour is relatively undocumented, and the PEP now proposes deprecating ex.args immediately, so Guido's well within his rights if he wants to change the behaviour. I was merely commenting from the 'its an unnecessary change to existing behaviour' angle, since the backwards compatible version gives the same behaviour of the new ex.message API as the version in the PEP, while leaving the now-deprecated ex.args API behaviour identical to that in Python 2.4. In other words, I'm looking for a *benefit* that comes from the behavioural change, rather than a 'but the current behaviour is undocumented anyway' response. If there's no actual benefit in breaking it, then why break it? :) >>> 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'. I'm talking about the specific context of the behaviour of 'return' in generators, not on the behaviour of ex.message in general. For normal exceptions, I agree '' is the correct default. For that specific case of allowing a return value from generators, and using it as the message on the raised StopIteration, *then* it makes sense for "return" to translate to "raise StopIteration(None)", so that generators have the same 'default return value' as normal functions. There's a reason I said it was just an observation - it has no effect on PEP 352 itself, only on a *different* syntax extension that hasn't even been officially suggested in a PEP (only mentioned in passing when discussing PEP 342). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com _______________________________________________ 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
