A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-February/077061.html below:

[Python-Dev] Backporting PEP 3127 to trunk

[Python-Dev] Backporting PEP 3127 to trunkEric Smith eric+python-dev at trueblade.com
Thu Feb 21 23:26:09 CET 2008
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.

Eric.

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4