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 scoder
Recipients Jim.Jewett, Mark.Shannon, amaury.forgeotdarc, benjamin.peterson, jcea, ncoghlan, pitrou, ron_adam, scoder
Date 2012-04-09.17:07:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333991223.04.0.413921862671.issue13897@psf.upfronthosting.co.za>
In-reply-to
Content
I can't speak for much outside of Cython, and Cython generated modules would best be regenerated with a newer Cython version anyway in order to work with Py3.3. I'm not sure that's currently required, though.

As long as there is a way to access these fields directly from the struct (with the usual preprocessor conditional), I don't think Cython will actually start to use the PyErr_[GS]etExcInfo() functions in CPython - simply for performance reasons. Inlining the access is just way faster than calling into external functions, especially when that happens more than once.

I'm still surprised about the general lack of resistence against incompatible changes to a public struct, though, especially when they come without an obvious gain. Is this really just for code beautification? I agree that this would be nice, but how can it be worth breaking code?

I don't see any objection to the generator related changes in this patch.
History
Date User Action Args
2012-04-09 17:07:03scodersetrecipients: + scoder, jcea, amaury.forgeotdarc, ncoghlan, pitrou, ron_adam, benjamin.peterson, Mark.Shannon, Jim.Jewett
2012-04-09 17:07:03scodersetmessageid: <1333991223.04.0.413921862671.issue13897@psf.upfronthosting.co.za>
2012-04-09 17:07:01scoderlinkissue13897 messages
2012-04-09 17:07:01scodercreate