Author ncoghlan
Recipients Arfrever, belopolsky, ezio.melotti, ilblackdragon, martin.panter, ncoghlan, pitrou, rbcollins, smurfix, xonatius
Date 2015-08-26.02:07:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Moving target version to 3.6 (since we're discussing adding a new public C API).

This is an interesting problem, as seeing an expanding API like this (PyEval_EvalCode -> PyEval_EvalCodeEx -> PyEval_EvalCodeEx2) suggests to me that we actually have a missing abstraction layer trying to get out.

My first reaction was to say "Hey, let's just make the eval loop function aware, and add PyEval_EvalFunction", but that creates a conceptual dependency loop we don't really want. 

So I asked myself a different question: why aren't we storing the qualname as a code object attribute, even though it's a known constant at compile time?

Looking at PEP 3155 ( ) it doesn't look like the question came up, and I don't recall it coming up either.

However, looking at I also don't see any reason why we *couldn't* provide a qualname field on code objects, such that f.__code__.co_qualname would give the same answer as f.__qualname__. The compiler already knows the qualname at compile time, we're just currently storing it as a separate constant that gets composed together with the code object at runtime.

My suspicion is that the reason this *wasn't* done is because it's a slightly more intrusive change to the code generation pipeline, but I currently suspect following up with that increase in compiler complexity would be a better option than making the PyEval_* API more complicated.
Date User Action Args
2015-08-26 02:07:17ncoghlansetrecipients: + ncoghlan, belopolsky, pitrou, rbcollins, ezio.melotti, smurfix, Arfrever, martin.panter, ilblackdragon, xonatius
2015-08-26 02:07:16ncoghlansetmessageid: <>
2015-08-26 02:07:16ncoghlanlinkissue2786 messages
2015-08-26 02:07:14ncoghlancreate