On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith firstname.lastname@example.org 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 after CO_FUTURE_WITH_STATEMENT).
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.