[Python-Dev] Backporting PEP 3127 to trunk

Neal Norwitz nnorwitz at gmail.com
Fri Feb 22 05:47:33 CET 2008

On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> I'm going to work on backporting PEP 3127, specifically the hex, oct(),
>  and bin() builtins.  I have bin() completed, and I'll check it in
>  shortly.  oct() will require a future import.  Does anyone have any
>  pointers for implementing this?  I understand (and have completed)
>  adding the future import, but what I don't understand is how to modify
>  the behavior of oct() for only the module where the future import is
>  execute.  Any rough ideas or pointers to existing code that does
>  something similar would be helpful.

See co_flags in PyCodeObject in Include/code.h.  When you are
compiling the code objects, you have access to the future flags.
These (can) get baked into the code objects when they are created.
You will need to make a new CO_* macro (0x10000 is the next available

In the past future imports have typically affected the parser or
semantics of the VM (e.g., future division).  In your case, you need
something different.  Thomas Wouters had a somewhat similar problem
when changing dict methods.  In his case though, he output different
op codes for the interpreter to execute to call the proper methods
(*).  You could use a similar trick here.  However, if you were doing
that, it begs the question of why not do as Guido suggests and just
replace the builtins.

If you only stored the info in the co_flags of code objects, the only
way I know of would be to access the callers frame and get its
co_flags.  This is yucky.  For example, what if oct() was called from
C code?

I think Guido's suggestion makes the most sense.  My description above
is just so people know what needs to be done, not a recommendation
that it ought to be done.


(*) - e.g. STORE_VIEWATTR in

More information about the Python-Dev mailing list