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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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. |
|
|