This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author daniel.urban
Recipients amaury.forgeotdarc, benjamin.peterson, brett.cannon, daniel.urban, georg.brandl, july, ncoghlan
Date 2011-03-10.17:13:55
SpamBayes Score 5.134854e-09
Marked as misclassified No
Message-id <1299777236.56.0.789197228339.issue11441@psf.upfronthosting.co.za>
In-reply-to
Content
So, I see four possible solutions:

1. If we get a tuple, create the new tuple, normalize the exception, and store it.  If we get a SyntaxError instance, use its args, create the new tuple, normalize, and store.  (In this case a SyntaxError instance will be created twice.)

2. If we get a tuple, create the new tuple and store it without normalization.  If we get a SyntaxError instance use its args to create the new tuple and store it without normalization.  (I think, that later it's still possible that a new SynaxError will be created, but we don't create it here.)

3. If we get a tuple, create the new tuple, and store it without normalization.  If we get a SyntaxError, take its args, create the new tuple, and call SyntaxError.__init__ with it. I think this will set all fields properly.

4. Like 3., but if we got a tuple, store the new tuple with normalization.

My patch currently does 1. 
My patch, without the PyErr_NormalizeException() call would be 2.
I think maybe 3. would be the best solution, or 4., if normalization is desired in all cases.

I can write a new patch, if the experts tell me what is the best solution from the four (or some other I didn't think of).
History
Date User Action Args
2011-03-10 17:13:56daniel.urbansetrecipients: + daniel.urban, brett.cannon, georg.brandl, amaury.forgeotdarc, ncoghlan, benjamin.peterson, july
2011-03-10 17:13:56daniel.urbansetmessageid: <1299777236.56.0.789197228339.issue11441@psf.upfronthosting.co.za>
2011-03-10 17:13:55daniel.urbanlinkissue11441 messages
2011-03-10 17:13:55daniel.urbancreate