This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

classification
Title: Add a builtin method to 'int' for base/radix conversion
Type: enhancement Stage: resolved
Components: Interpreter Core, Library (Lib) Versions: Python 3.2
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: cvrebert, mark.dickinson, r.david.murray, terry.reedy, ubershmekel
Priority: normal Keywords:

Created on 2009-08-25 19:35 by ubershmekel, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (9)
msg91958 - (view) Author: Yuval Greenfield (ubershmekel) * Date: 2009-08-25 19:35
In javascript and java each number has a toString method which allows 
for easy string representation in different bases. If the function int(x[, base]) exists as a builtin, the inverse should at least be 
somewhere in the standard library. Personally I believe a "to_string" 
method would work but would defeat "There should be one way to do it". 
Perhaps a method called "radix" or "base_convert" which requires a base 
to convert parameter won't take the place of str(number).

Here are a few possible implementations:
http://code.activestate.com/recipes/222109/
http://code.activestate.com/recipes/111286/
http://pastebin.com/f54dd69d6
msg91959 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-08-25 19:45
This seems like the sort of idea that should be floated on the python-
ideas mailing list or comp.lang.python first, both to find out what 
support there is and to pin down precise semantics.

We already have int to string conversions in bases 2, 8, 10 and 16;  what 
are the use-cases for conversions in other bases?
msg91960 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-08-25 19:53
See http://mail.python.org/pipermail/python-dev/2006-January/059789.html 
for a previous related discussion.
msg91996 - (view) Author: Yuval Greenfield (ubershmekel) * Date: 2009-08-27 07:03
Use case - 'hashing' a counter for example like video ID's in youtube. 
One could use a regular int internally and publish a shorter 62-base id 
for links.

Guido said on http://mail.python.org/pipermail/python-dev/2006-
January/059923.html
"I think we ought to let this sit for a while and come back to it in a
few week's time. Is 'base' really the right name? It could just as
well be considered a conversion in the other direction. In common
usage, 'base' and 'radix' are about synonymous (except no-one uses
radix). Pethaps the 2nd argument should not be a keyword argument?

Also, this discussion made me wonder if conversions using other bases
than 10 should even be built-ins. A library module seems a more
appropriate place"

I'm hoping 182 weeks of clarity could help iron this issue out.
msg92010 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-08-27 19:04
> I'm hoping 182 weeks of clarity could help iron this issue out.

:-)

I really think should bring this up on the python-ideas mailing list[1];  
it's much more likely to get resolved one way or the other if you do.

[1] http://mail.python.org/mailman/listinfo/python-ideas
msg113439 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-09 18:33
I believe this is covered by the PEP3003 3.2 change moratorium.
msg113441 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-08-09 18:34
> I believe this is covered by the PEP3003 3.2 change moratorium.

No, I don't think so.  My understanding is that PEP 3003 doesn't cover new methods on builtin types.  int.from_bytes and int.to_bytes are examples of new methods that were added for 3.2.
msg113448 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-08-09 18:45
In fact, PEP 3003 says explicitly, under "Case-by-Case Exemptions":

"""
New methods on built-ins

    The case for adding a method to a built-in object can be made.
"""

So I'm changing the version back to 3.2.  Having said that, I'm still -0 on this change.  I can see some (small) value for bases 36 and 62 in particular, but little use for the other bases.

Incidentally, Yuvgoog Greenle did bring this up on the python-ideas list (thank you!).  The thread starts here:

http://mail.python.org/pipermail/python-ideas/2009-August/005611.html

The thread was rather inconclusive:  it got bogged down in discussions over whether bases 37+ should be allowed, whether there should be options to specify the digit-set used, and the like.
msg186683 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-04-12 22:20
Given an inconclusive python-ideas thread, Mark's -0, and the age of the issue, I'm going to close this.  If someone wants to bring it up on python-ideas again, they can open an new issue if consensus is reached.
History
Date User Action Args
2022-04-11 14:56:52adminsetgithub: 51032
2013-04-12 22:20:58r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg186683

stage: resolved
2010-08-09 18:45:25mark.dickinsonsetmessages: + msg113448
versions: + Python 3.2, - Python 3.3
2010-08-09 18:34:51mark.dickinsonsetmessages: + msg113441
2010-08-09 18:33:13terry.reedysetnosy: + terry.reedy

messages: + msg113439
versions: + Python 3.3, - Python 2.7, Python 3.2
2009-08-27 19:04:40mark.dickinsonsetmessages: + msg92010
2009-08-27 07:03:21ubershmekelsetmessages: + msg91996
2009-08-26 02:07:01cvrebertsetnosy: + cvrebert
2009-08-25 19:53:35mark.dickinsonsetmessages: + msg91960
2009-08-25 19:45:25mark.dickinsonsetnosy: + mark.dickinson
messages: + msg91959
2009-08-25 19:35:40ubershmekelcreate