[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Thank you everyone for increasing my understanding. :) Terry J Reedy wrote: > [snip everything I now agree with, which is most of Terry's comment] > 3. Every core usage of __int__ looks for __index__ also. Int() does not > do this now, but '

[issue19995] hex() and %x, oct() and %o do not behave the same

Terry J. Reedy added the comment: It seems to me that anything that is an 'integer' that can be turned into an int without loss of information (has .__index__) is logically a 'number' that can be turned into an int possibly with loss of information (has .__int__). So perhaps one of the follow

[issue19995] hex() and %x, oct() and %o do not behave the same

Eric V. Smith added the comment: Yes, looking through Objects/unicodeobject.c, 'u', 'i', and 'd' are treated the same everywhere. -- ___ Python tracker ___ _

[issue19995] hex() and %x, oct() and %o do not behave the same

Guido van Rossum added the comment: AFAIK %i and %d are the same. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Thank you, Victor and Serhiy, for your pointers into the code. I'm hoping we have general agreement about %c, %o, %x, and %X and having them use __index__ only (using __int__ would open the door to float conversions). I still have a question about %i, though. T

[issue19995] hex() and %x, oct() and %o do not behave the same

Serhiy Storchaka added the comment: In addition, PyLong_AsLong() calls __int__, while PyLong_AsUnsignedLong() doesn't call __int__. -- ___ Python tracker ___ ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: > Antoine, > > Does that mean you are reducing your previous statement of > > > So trying __index__ in str.format() sounds like a distraction. > > to "using __index__ for %d, %i, and %u is not correct, but is correct > for %c, %o, %x, and %X" ? Ah, yes, sorry

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Antoine, Does that mean you are reducing your previous statement of > So trying __index__ in str.format() sounds like a distraction. to "using __index__ for %d, %i, and %u is not correct, but is correct for %c, %o, %x, and %X" ? -- ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: > Antoine, if I understand you correctly, you are saying that any type > that defines __index__ is an integer, and should therefore also define > __int__, in which case Python can just use __int__ and not worry about > __index__? ... is an integer-like, yes. >

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Antoine, if I understand you correctly, you are saying that any type that defines __index__ is an integer, and should therefore also define __int__, in which case Python can just use __int__ and not worry about __index__? Here's the problem with that: --> '%x

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: > In other words > > - if %d or %u is specified, try __int__, then __index__ > (according to the docs, u is obsolete and identical to d) Again, I don't think trying __index__ is useful. > - if %i, %o, %x, %X, or %c is specified, try only __index__ I t

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Ethan Furman previously stated: --- > So the complete list of spcecifiers then is d, i, o, u, U, and c [1], and they > should work if __index__ works. Okay, so 'd' then should be considered a conversion operation, whilst the others sho

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: > --> '%x' % 3.14 # calls __int__ > '3' > > One of those behaviours is wrong. Which? For '%x' and '%o', it probably doesn't make sense to convert the float to an int. (however, it does make sense for other formatters, such as '%d') -- __

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Antoine Pitrou opined: -- > I'm with Guido: it doesn't really make sense to allow __index__ but not > __int__ on > a type. So trying __index__ in str.format() sounds like a distraction. --> hex(3.14) # calls __index__ Traceback (most rece

[issue19995] hex() and %x, oct() and %o do not behave the same

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue19995] hex() and %x, oct() and %o do not behave the same

Antoine Pitrou added the comment: I'm with Guido: it doesn't really make sense to allow __index__ but not __int__ on a type. So trying __index__ in str.format() sounds like a distraction. -- ___ Python tracker ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Eric V. Smith commented: > If you were going to make this change, I'd think you'd have to look > for __index__ and then __int__. Does the order matter? Are there any types (and should there be) that would have both and return different a

[issue19995] hex() and %x, oct() and %o do not behave the same

Eric V. Smith added the comment: If you were going to make this change, I'd think you'd have to look for __index__ and then __int__. But I'll admit I haven't thought through all of the ramifications. It would be interesting to see what tests would break. -- ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Guido van Rossum added the comment: Also (the tracker email interface swallowed this): > it is possible to want a type that can be used as an index or slice but that > is still not a number I'm sorry, but this requirement is absurd. An index *is* a number. You have to make up your mind. (I kno

[issue19995] hex() and %x, oct() and %o do not behave the same

Guido van Rossum added the comment: Not so fast. Currently, even in Python 3, '%d' % 3.14 returns '3'. "Fixing" this will likely break a huge amount of code. -- versions: +Python 3.5 -Python 3.4 ___ Python tracker

[issue19995] hex() and %x, oct() and %o do not behave the same

Eric V. Smith added the comment: Yes, I think adding __index__ to d, i, o, u, U, and c is the correct thing to do here. -- ___ Python tracker ___ ___

[issue19995] hex() and %x, oct() and %o do not behave the same

Serhiy Storchaka added the comment: > > Did I mention __index__ is an unfortunate name for the current trend for > > this method? > Yes, but it's probably too late to change that now. Also, a fully precise > name would be something like: > > __to_int_exact_iff_object_has_integer_nature__ :)

[issue19995] hex() and %x, oct() and %o do not behave the same

STINNER Victor added the comment: > Are we in agreement? Start maybe on writing unit tests :-) IMO all int-like objects should behave the same. I don't see any good reason why hex(value) would succeed whereas "%x" % value fails. Both should succeed (or both should fail). -- __

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Hmmm... Well, much as I hate to say it, it's sounding like the correct solution here is to have %o and %x work when __index__ is available, instead of the other way around. :( .format is not an issue because one must specify one's own if inheriting from objec

[issue19995] hex() and %x, oct() and %o do not behave the same

Stefan Krah added the comment: > Did I mention __index__ is an unfortunate name for the current trend for this > method? Yes, but it's probably too late to change that now. Also, a fully precise name would be something like: __to_int_exact_iff_object_has_integer_nature__ :) > When you say

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Did I mention __index__ is an unfortunate name for the current trend for this method? Stefan Krah commented: -- > memoryview, struct and probably also array.array accept __index__. When you say "accept __index__" do you mean for use as indice

[issue19995] hex() and %x, oct() and %o do not behave the same

Stefan Krah added the comment: Ethan Furman wrote: > The current meaning is unfortunate in that it is possible to want a type that > can be used as an index or slice but that is still not a number, and in fact > won't be used as a number in any scenario _except_ bin(), hex(), and oct(). memoryv

[issue19995] hex() and %x, oct() and %o do not behave the same

STINNER Victor added the comment: $ python Python 2.7.5 (default, Nov 12 2013, 16:18:42) >>> import numpy >>> hex(numpy.uint16(257)) '0x101' >>> "%x" % numpy.uint16(257) '101' >>> x=numpy.uint16(257) >>> x.__int__() 257 >>> x.__index__() 257 -- ___ P

[issue19995] hex() and %x, oct() and %o do not behave the same

Ethan Furman added the comment: Victor Stinner commented: - > I never understood the difference between "long" (__int__ method) > and "index" (__index__ method). Is the difference on the behaviour > of floating point numbers? __index__ was originally added so that non-int

[issue19995] hex() and %x, oct() and %o do not behave the same

Eric V. Smith added the comment: It seems to me that by giving it an __index__ method, you're saying it can be used as an integer. It's not surprising to me that hex(), oct(), and bin() would work with a Grade.F object. If anything, I'd say that more places should use __index__ than currently

[issue19995] hex() and %x, oct() and %o do not behave the same

STINNER Victor added the comment: Calls: * hex()/oct() => PyNumber_ToBase() => PyNumber_Index(). * PyUnicode_Format() => mainformatlong() => PyNumber_Long() I never understood the difference between "long" (__int__ method) and "index" (__index__ method). Is the difference on the behaviour of fl

[issue19995] hex() and %x, oct() and %o do not behave the same

New submission from Ethan Furman: Using Enum to illustrate: --> class Grade(enum.Enum): ... A = 4 ... B = 3 ... C = 2 ... D = 1 ... F = 0 ... def __index__(self): ... return self._value_ --> ['miserable'][Grade.F] 'miserable' --> '%x'