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.

Title: Backport oct() and hex() to use __index__
Type: Stage:
Components: Interpreter Core Versions: Python 2.6
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, brett.cannon, eric.smith, georg.brandl
Priority: critical Keywords: 26backport, patch

Created on 2008-03-17 17:51 by brett.cannon, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
oct_and_hex_py3k.patch benjamin.peterson, 2008-04-27 19:04
Messages (11)
msg63695 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-03-17 17:51
oct() and hex() need to use __index__ when available and then emit a
Py3K warning when they fall back on __oct__ and __hex__.
msg64270 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-03-21 20:13
Shouldn't we leave alone oct() and hex() (there is another issue for
deprecation warning for __oct__ and __hex__), and let people use the
versions from future_builtins?
msg65859 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-04-27 00:31
This is what I'd like to do: In builtin oct/hex check if the special
method is declared. If it is, Py3k warn and use it. If not, check if we
can do it the Py3k way (with PyNumber_ToBase). Sound good?
msg65863 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-04-27 01:23

That is a possibility. Would need to add the proper Py3K warning to the 
current builtins, though.


You don't want to warn if it will work for Py3K, so don't warn if 
__index__ is used.
msg65865 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-04-27 01:26
I meant not to. Sorry, that wasn't clear.
msg65881 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-04-27 09:36
I don't assume there are too many people using oct() and hex() with
custom types anyway :)

Since PyNumber_ToBase and the new oct() format octal numbers with "0o"
instead of "0", I still think it's better if you need to import the new
oct() from future_builtins. For hex(), I have no preference.
msg65892 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-04-27 19:04
Here's a patch for that. It warns for hex() when __hex__ is used,
otherwise it uses __index__. (This doesn't work for old style classes
because ob_tp->tp_as_number->tp_hex is filled.) Use of oct() just gets a
warning. The __hex__ and __oct__ methods of builtin number objects
should probably be removed.
msg67008 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-05-17 18:49
The warning message for oct() should include that the output will be
different too. Else this is fine with me.
msg67013 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-05-17 19:23
Done in r63425.
msg67015 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-05-17 20:11
I have reverted this. See
msg67768 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-06-06 14:18
This was rejected by Guido.
Date User Action Args
2022-04-11 14:56:31adminsetgithub: 46590
2008-06-06 14:18:08benjamin.petersonsetstatus: pending -> closed
resolution: rejected
messages: + msg67768
2008-05-17 20:36:02eric.smithsetnosy: + eric.smith
2008-05-17 20:11:48benjamin.petersonsetstatus: closed -> pending
resolution: fixed -> (no value)
messages: + msg67015
2008-05-17 19:23:32benjamin.petersonsetstatus: open -> closed
resolution: fixed
messages: + msg67013
2008-05-17 18:49:32georg.brandlsetmessages: + msg67008
2008-04-27 19:08:36benjamin.petersonlinkissue2352 superseder
2008-04-27 19:04:45benjamin.petersonsetfiles: + oct_and_hex_py3k.patch
keywords: + patch
messages: + msg65892
2008-04-27 09:36:27georg.brandlsetmessages: + msg65881
2008-04-27 01:26:51benjamin.petersonsetmessages: + msg65865
2008-04-27 01:23:42brett.cannonsetmessages: + msg65863
2008-04-27 00:31:25benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg65859
2008-03-21 20:13:50georg.brandlsetnosy: + georg.brandl
messages: + msg64270
2008-03-17 20:10:36brett.cannonsetpriority: release blocker -> critical
2008-03-17 17:51:06brett.cannoncreate