I wonder if, in order to change the behavior of various built-in functions, it wouldn't be easier to be able to write
from future_builtins import oct, hex # and who knows what else
Agreed with your approach for bin().
On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith email@example.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. I also need a name for the future import statement.
Also, I notice in py3k that __hex__ and __oct__ have vanished, and instead hex() and oct() just uses the __index__ machinery to produce a number, then converts that to a string. So I'm thinking that maybe we could use the same future import statement that controls oct()'s behavior to also switch hex() and oct() to the py3k behavior. Or, maybe we should use a different future import? Or, I guess, not do this at all. But I think it's a good idea.
I guess another issue is changing hex()'s behavior of adding a trailing L for longs. I don't really see the value in this, and maybe it should also change with a future import statement.
For bin(), I just used the py3k behavior, and didn't implement a __bin__ method. I'm also not adding a trailing L for longs. I think that makes the most sense.
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org