[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Calin Culianu added the comment: Ok, Guido, thanks. Fair enough. So regardless: what is the problem exactly if a C function expects an int but gets given a float? Why does such strictness matter, in that it required a whole other set of __index__ etc to be added? I am having trouble seeing

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Guido van Rossum added the comment: Claim, you need to tone down the rhetoric. Python is not C++ and user expectations are different. You are the one who is fighting windmills here. -- ___ Python tracker

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

(2002!!). So.. in python this conversion is well defined. And has always been, by __int__. I think the introduction of __index__ versus __int__ may be a mistake, especially if it is designed to "solve" just this problem -- which as yet, has to be clearly argued for as to **why**

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

or mailing lists. It was a partial solution. It caught unexpected floats, but not other non-integer numbers. Later, the __index__ special method was introduced specially to distinguish objects which can be implicitly converted to integer from these which can be explicitly converted to integer

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Calin Culianu added the comment: Hi, I'm cculianu, the reporting user. May I get a link or some background for the motivation for this change? It seems to me that there are vague allusions to "Decimal -> int cause problems in past", or some such, and I'd like to read the arguments presented

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Mark Dickinson added the comment: For the record, #37999 is the issue that turned the deprecation warnings into errors for Python 3.10. (But as Serhiy says, please open a new issue, or start a discussion on one of the mailing lists.) -- ___

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Serhiy Storchaka added the comment: This issue was closed more than 2.5 years ago. The changes were made in 3.8, not in 3.10. BTW, 3.8 only accepts security fixes now. Please open a new issue for new discussion. -- ___ Python tracker

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Mark Dickinson added the comment: @arhadthedev: Thanks for highlighting the issue. > we need to check if the problem really has place and the PR needs to be > retracted until PyQt5 is ported to newer Python C API I'm not particularly impressed by the arguments from cculianu. This was the

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Oleg Iarygin added the comment: The reporter gave more details (): > Literally this is ok in C++ with Qt: > > float x = 2.3, y = 1.1; > auto p = QPoint(x, y); // QPoint only takes 2 int params.. this works in >

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Oleg Iarygin added the comment: Here is a report that this change breaks PyQt5 on Fedora: > [...] > > Why do I care? This breaks tons of existing PyQt5 code out there, for > example. I wasn't aware of this change to the

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Patrick Yang added the comment: I ended up in this issue after I learnt the following from the Python Library Reference Manual. float(..). For a general Python object x, float(x) delegates to x.__float__(). If __float__() is not defined then it falls back to __index__

[issue40129] Add test classes for custom __index__, __int__, __float__ and __complex__

Change by Serhiy Storchaka : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue40129] Add test classes for custom __index__, __int__, __float__ and __complex__

Raymond Hettinger added the comment: I don't think this makes the world better. It just makes it more intertwined. Currently, I can read the test code in isolation and understand it. But with the proposed PR, a person now needs to know more of what is in test_support. I really like

[issue40129] Add test classes for custom __index__, __int__, __float__ and __complex__

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +18618 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19262 ___ Python tracker

[issue40129] Add test classes for custom __index__, __int__, __float__ and __complex__

New submission from Serhiy Storchaka : There are many tests for int-like objects (which implement custom __index__ or __int__ methods) in different files. There are less tests for float-like objects (with the __float__ method). There are even tests for complex-like (with the __complex__

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

STINNER Victor added the comment: > Serhiy: any thoughts about what version should be targeted for eventual > removal of the functionality deprecated in this PR? 3.10? IMHO it should be done at the *very beginning* of a release cycle. Python 3.9.0 alpha 1 *and* alpha 2 versions have already

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Mark Dickinson added the comment: Serhiy: any thoughts about what version should be targeted for eventual removal of the functionality deprecated in this PR? 3.10? -- ___ Python tracker

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Change by Mark Dickinson : -- pull_requests: +13659 pull_request: https://github.com/python/cpython/pull/13740 ___ Python tracker ___

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Serhiy Storchaka added the comment: New changeset bdbad71b9def0b86433de12cecca022eee91bd9f by Serhiy Storchaka in branch 'master': bpo-20092. Use __index__ in constructors of int, float and complex. (GH-13108) https://github.com/python/cpython/commit/bdbad71b9def0b86433de12cecca022eee91bd9f

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Mark Dickinson added the comment: I like the delegation of `float` and `complex` to use `__index__` that was introduced in GH-13108; it would be nice to have that regardless of which solution is decided on for `__int__` and `__index__

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36846] range_iterator does not use __index__

Serhiy Storchaka added the comment: This is a duplicate of issue17576. -- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie)

[issue36846] range_iterator does not use __index__

Rémi Lapeyre added the comment: Hi @bup, thanks for opening a new bug report. I'm not sure I get what is the issue though. Could you attach a more readable example and explain exactly when you expect __index__ to be called? -- nosy: +remi.lapeyre

[issue36846] range_iterator does not use __index__

. That is what happens right now and it can prevent the __index__ method defined for an int subtype being called in certain situation such as this one. Here's a silly but valid demonstration of what happens when there is more than 1 way to skin a... index. Apologies if it is unreadable but I wanted

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Serhiy Storchaka added the comment: See also the discussion on the duplicated issue33039. Few months ago I wrote the PR that makes constructors of int, float and complex to fall back to __index__ if corresponding special methods __int__, __float__ and __complex__ are not defined. I did

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Change by Rémi Lapeyre : -- pull_requests: +13023 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +13022 stage: test needed -> patch review ___ Python tracker ___

[issue33039] int() and math.trunc don't accept objects that only define __index__

Serhiy Storchaka added the comment: Then let to continue the discussion on the older issue which has larger discussion. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> type() constructor should bind __int__ to __

[issue33039] int() and math.trunc don't accept objects that only define __index__

by Nick Coghlan is better than the one of Amitava Bhattacharyya, "adding a call to `nb_index` (if that slot exists) in `_PyLong_FromNbInt`" though. One thing to note regarding the proposed patch: the following stops to work and raises a RecursionError since __index__ == __int__:

[issue33039] int() and math.trunc don't accept objects that only define __index__

Change by Rémi Lapeyre : -- keywords: +patch pull_requests: +13020 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Miro Hrončok added the comment: Relevant NumPy issue: https://github.com/numpy/numpy/issues/13412 -- nosy: +hroncok ___ Python tracker ___

[issue33039] int() and math.trunc don't accept objects that only define __index__

Cheryl Sabella added the comment: Rémi, Are you still working on the patch for this? Thanks! -- nosy: +cheryl.sabella ___ Python tracker ___

[issue33002] Making a class formattable as hex/oct integer with printf-style formatting requires both __int__ and __index__ for no good reason

Serhiy Storchaka added the comment: Resolved in issue36048. -- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Deprecate implicit truncating when convert Python numbers to C integers: use __index__,

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Serhiy Storchaka added the comment: New changeset 6a44f6eef3d0958d2347190b3e2d1222c2e9 by Serhiy Storchaka in branch 'master': bpo-36048: Use __index__() instead of __int__() for implicit conversion if available. (GH-11952) https://github.com/python/cpython/commit

[issue33039] int() and math.trunc don't accept objects that only define __index__

Rémi Lapeyre added the comment: Yes it is. Thanks for finding that @Serhiy. Since nobody objected to the change on the mailing list and people seem to agree in issue 20092: [R. David Murray] To summarize for anyone like me who didn't follow that issue: __index__ means the object can

[issue33039] int() and math.trunc don't accept objects that only define __index__

Serhiy Storchaka added the comment: Is not this a duplicate of issue20092? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Rémi Lapeyre added the comment: > I am not sure what to with the int constructor. Should it try __index__ > before __int__? Or just make __index__ without __int__ setting the nb_int > slot as was proposed by Nick in issue33039? Shouldn't it try only __int__ since this wil

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Serhiy Storchaka added the comment: I am not sure what to with the int constructor. Should it try __index__ before __int__? Or just make __index__ without __int__ setting the nb_int slot as was proposed by Nick in issue33039? -- ___ Python

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

STINNER Victor added the comment: See also bpo-34423: "Overflow when casting from double to time_t, and_PyTime_t" or "How to reduce precision loss when converting arbitrary number to int or float?". -- ___ Python tracker

[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

Change by STINNER Victor : -- title: Deprecate implicit truncating when convert Python numbers to C integers -> Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__ ___ Python tracker <

[issue33039] int() and math.trunc don't accept objects that only define __index__

Serhiy Storchaka added the comment: See also issue33039. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list

[issue33039] int() and math.trunc don't accept objects that only define __index__

Nick Coghlan added the comment: @Rémi Aye, filling out derived slots is one of the things PyType_Ready does. This would need a discussion on python-dev before going ahead and doing it though, as the closest equivalent we have to this right now is the "negative" derivation, where overriding

[issue33039] int() and math.trunc don't accept objects that only define __index__

Rémi Lapeyre added the comment: >I think we should also consider changing the type creation behaviour in 3.8 @ncoghlan is this what's being done in PyTypeReady? -- nosy: +remi.lapeyre ___ Python tracker

[issue33002] Making a class formattable as hex/oct integer with printf-style formatting requires both __int__ and __index__ for no good reason

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33039] int() and math.trunc don't accept objects that only define __index__

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33039] int() and math.trunc don't accept objects that only define __index__

Nick Coghlan <ncogh...@gmail.com> added the comment: Marking this as a documentation enhancement request for now, but I think we should also consider changing the type creation behaviour in 3.8 to implicitly add __int__ and __trunc__ definitions when __index__ is defined, but they

[issue33039] int() and math.trunc don't accept objects that only define __index__

New submission from Nick Coghlan <ncogh...@gmail.com>: (Note: I haven't categorised this yet, as I'm not sure how it *should* be categorised) Back when the __index__/nb_index slot was added, the focus was on allowing 3rd party integer types to be used in places where potentially

[issue33002] Making a class formattable as hex/oct integer with printf-style formatting requires both __int__ and __index__ for no good reason

Mark Dickinson added the comment: Agreed that this seems wrong. -- nosy: +eric.smith, mark.dickinson ___ Python tracker ___

[issue33002] Making a class formattable as hex/oct integer with printf-style formatting requires both __int__ and __index__ for no good reason

Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment: To be clear, this is a problem with old-style (printf-style) formatting, and applies to both bytes formatting and str formatting. So a class like: class Foo: def __index__(self): return 1 wil

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment: Pingback from #33002, which is caused by the fact that parts of the CPython code base that use PyNumber_Index for type conversion still pre-check for valid types with PyNumber_Check, meaning that a type with __i

[issue33002] Making a class formattable as hex/oct integer requires both __int__ and __index__ for no good reason

Josh Rosenberg <shadowranger+pyt...@gmail.com> added the comment: Note: Obviously, defining __index__ without defining __int__ is a little strange (it's *equivalent* to int, but can't be *coerced* to int?), so yet another fix would be addressing #20092 so it wouldn't be possible for

[issue33002] Making a class formattable as hex/oct integer requires both __int__ and __index__ for no good reason

method). In Python 3, this was changed to perform the conversion via __index__ for the %o, %x and %X format types (to match how oct and hex behave), not __int__, but the pre-check for validity in unicodeobject.c's mainformatlong function is still based on PyNumber_Check, not PyIndex_Check, and PyNumber

[issue28767] Readd __index__ support on ipaddress objects

Josh Rosenberg added the comment: >From the original bugs, it looks like people liked being able to directly >produce the hex of the IP addresses using hex(). I'll admit I'm only +0.5 on >restoring __index__; having them be equivalent to int, not just convertable, >doesn't seem

[issue28767] Readd __index__ support on ipaddress objects

Serhiy Storchaka added the comment: Why __index__ support is needed? -- nosy: +serhiy.storchaka ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue28767] Readd __index__ support on ipaddress objects

New submission from Josh Rosenberg: It looks like, due to #16722, in #15559, __index__ was removed from ipaddress objects. #16722 was fixed a few months later, but the comments asking for it to be readded were put on a closed issue, so no one noticed. Can __index__ support be readded now

[issue27177] re match.group should support __index__

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue27177] re match.group should support __index__

Roundup Robot added the comment: New changeset 0303ab246152 by Serhiy Storchaka in branch 'default': Issue #27177: Match objects in the re module now support index-like objects https://hg.python.org/cpython/rev/0303ab246152 -- nosy: +python-dev ___

[issue27177] re match.group should support __index__

Serhiy Storchaka added the comment: Interesting. This is very unusual but reasonable use case. -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue27177] re match.group should support __index__

Jeroen Demeyer added the comment: My use case is SageMath: http://trac.sagemath.org/ticket/20750 -- ___ Python tracker ___

[issue27177] re match.group should support __index__

Serhiy Storchaka added the comment: What is the use case? -- ___ Python tracker ___ ___ Python-bugs-list

[issue27177] re match.group should support __index__

Xiang Zhang added the comment: Attach a patch to add this feature to Py3.6. -- nosy: +xiang.zhang Added file: http://bugs.python.org/file43396/issue27177.patch ___ Python tracker

[issue27177] re match.group should support __index__

Matthew Barnett added the comment: It would be a bug if it was supported but gave the wrong result. It has never been supported (the re module predates PEP 357), so it's a new feature. -- ___ Python tracker

[issue27177] re match.group should support __index__

Jeroen Demeyer added the comment: I would still argue that it's a bug. The intention of PEP 357 is that __index__ should be used whenever some object needs to be converted to a Py_ssize_t, which is exactly what you do here. -- ___ Python tracker

[issue27177] re match.group should support __index__

Serhiy Storchaka added the comment: This looks as new feature and can go only in 3.6. -- nosy: +serhiy.storchaka stage: -> needs patch type: -> enhancement versions: +Python 3.6 -Python 2.7 ___ Python tracker

[issue27177] re match.group should support __index__

New submission from Jeroen Demeyer: ``` >>> class zero(object): ... def __index__(self): ... return 0 ... >>> z = zero() >>> import re >>> p = re.compile('(a)b') >>> m = p.match('ab') >>> m.group(0) 'ab' >>>

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Changes by Ethan Furman et...@stoneleaf.us: -- nosy: -ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20092 ___ ___ Python-bugs-list

__index__

Hello, I have a Bloom filter class and want to (partially) serialize instances using hex() or oct(). Instances are mutable, so I can't inherit from long. I thought I'd found the answer when I came across __index__, https://docs.python.org/2/reference/datamodel.html#object.__index__

Re: __index__

On 11/1/14 12:56 PM, duncan smith wrote: Hello, I have a Bloom filter class and want to (partially) serialize instances using hex() or oct(). Instances are mutable, so I can't inherit from long. I thought I'd found the answer when I came across __index__, https://docs.python.org/2

Re: __index__

On 01/11/14 16:56, duncan smith wrote: [snip] Sorry, forgot to add that I'm using Python 2.7.6 on Ubuntu 14.04. Cheers. Duncan -- https://mail.python.org/mailman/listinfo/python-list

Re: __index__

__index__, it doesn't seem to work as I expected it to. Just above your link in the docs is __oct__ and __hex__, which are used to implement oct() and hex(): https://docs.python.org/2/reference/datamodel.html#object.__oct__ In Python 2 __oct__ and __hex__ are used for oct() and hex

Re: __index__

I'd found the answer when I came across __index__, it doesn't seem to work as I expected it to. Just above your link in the docs is __oct__ and __hex__, which are used to implement oct() and hex(): https://docs.python.org/2/reference/datamodel.html#object.__oct__ In Python 2 __oct__

Re: __index__

On 11/01/2014 11:29 AM, Ethan Furman wrote: But I agree with Net ... Oops, should have ben 'Ned' -- apologies! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Amitava Bhattacharyya added the comment: Hi Ethan, I tried adding a call to `nb_index` (if that slot exists) in `_PyLong_FromNbInt`, but that didn't work. Based on your comment it seems the fix would be to patch this at object creation. I will check where that happens (bear with me while I

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Ethan Furman added the comment: Thank you for your efforts, Amitava. Please also sign a Contributor's License Agreement so we can actually use your code. :) http://www.python.org/psf/contrib/ -- ___ Python tracker rep...@bugs.python.org

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

R. David Murray added the comment: There will be a corporate agreement from Bloomberg sometime soon (and that will be required in this case, not an individual agreement). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20092

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Amitava Bhattacharyya added the comment: I did fill in the contributor agreement form and e-signed it, maybe it takes some time for my profile to be updated? But I guess I need to wait for the corporate agreement. :) -- ___ Python tracker

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Amitava Bhattacharyya added the comment: I started working on this issue as part of the Bloomberg Python Sprint (https://etherpad.mozilla.org/LjZPQ55oZs). Ethan, can you confirm if the attached test case summarizes the issue correctly? I tried to hook _PyLong_FromNbInt to check nb_index but

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

, and if that type had __index__ but not __int__ then bind __int__ to __index__. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20092 ___ ___ Python-bugs

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Changes by Terry J. Reedy tjre...@udel.edu: -- stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20092 ___ ___ Python-bugs-list

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Terry J. Reedy added the comment: I believe this is my suggestion 2) in msg206715 of #19995, and I think it better than 3) (and 1) alone). Thanks for moving this forward. I believe what Guido said is that indexes (integers in the broad sense) are (or should be) a subset of things convertible

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

is that if an actual int is needed from an actual integer type (not float, not complex, not etc.), then __index__ is used. If __index__ is not defined by some numeric type then it will not be considered a true int in certain key places in Python, such as as indices, arguments to hex(), etc. Making

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

R. David Murray added the comment: Ah, I see. A link to that issue would have been helpful :). To summarize for anyone like me who didn't follow that issue: __index__ means the object can be losslessly converted to an int (is a true int), while __int__ may be an approximate conversion. Thus

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

. .. method:: object.__index__(self) - Called to implement :func:`operator.index`. Also called whenever Python needs - an integer object (such as in slicing, or in the built-in :func:`bin`, - :func:`hex` and :func:`oct` functions). Must return an integer. + Called to implement :func

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

R. David Murray added the comment: Nah, splitting it doesn't seem worth it unless you think the patch won't make it in. (Not that I looked at it earlier, but he patch on the issue doesn't look like what you just posted here...and here there's a typo: shuld). --

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Ethan Furman added the comment: I updated it as I liked your wording better. :) Doing more testing to see if anything else needs fixing before I make the next patch for the tracker on that issue. -- ___ Python tracker rep...@bugs.python.org

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

New submission from Ethan Furman: In order to create a coherent integer type class both __int__ and __index__ must be defined or the resulting instances will behave inconsistently in different places. For example, if __index__ is not defined then the class cannot be used in slices

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Benjamin Peterson added the comment: __ne__ is not bound to __eq__. The comparison code simply falls back onto __eq__ if __ne__ is not defined. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20092

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Ethan Furman added the comment: True. I meant similar in that Python will use what's available to fill in the blank: class has __eq__ but user tried != ? use __eq__ and invert result class has __index__ but user tried int() ? use __index__

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20092 ___

[issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not

R. David Murray added the comment: It is not clear to me that that would be correct, though. Isn't the whole point of __index__ that some types can act as indicies even though they are *not* integers? Shouldn't it be up to the type to decide if converting them to int is a sensible thing

[issue19988] hex() and oct() use __index__ instead of __int__

, if __index__ is added to an Enum (not IntEnum) subclass, it will have the same wierdness. Guido van Rossum stated: For the difference between %x and hex() please open another issue (you might want to track down the cause in the source first so you can add a patch or at least

[issue19988] hex() and oct() use __index__ instead of __int__

New submission from Ethan Furman: In Py3k __hex__ and __oct__ were removed, and hex() and oct() switched to use __index__. hex() and oct() should be using __int__ instead. Having read through PEP 357 [1] I see that __index__ is /primarily/ concerned with allowing arbitrary objects to be used

[issue19988] hex() and oct() use __index__ instead of __int__

Serhiy Storchaka added the comment: __index__() is used because float has __int__ but not __index__. (42.0).__int__() 42 (42.0).__index__() Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'float' object has no attribute '__index__' -- nosy

[issue19988] hex() and oct() use __index__ instead of __int__

Antoine Pitrou added the comment: Indeed, the definition and use of __index__ has derived since PEP 357. Nowadays, __index__ means can be converted to an int without loss. In any case, I find the behaviour of your logical type a bit dubious. If it's like bool but ternary, it *should* convert

[issue19988] hex() and oct() use __index__ instead of __int__

Mark Dickinson added the comment: hex() and oct() should be using __int__ instead. Strong -1 from me. I wouldn't want `hex(45.3)` to work, and `hex(45.0)` working isn't much better. -- ___ Python tracker rep...@bugs.python.org

[issue19988] hex() and oct() use __index__ instead of __int__

Stefan Krah added the comment: -1 from me as well. I would not want to audit a large program for accidentally converted floats. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19988

[issue19988] hex() and oct() use __index__ instead of __int__

Raymond Hettinger added the comment: Guido, I believe that __index__ was your initiative. Do you care to opine on this one? -- assignee: - gvanrossum nosy: +gvanrossum, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue19988] hex() and oct() use __index__ instead of __int__

Guido van Rossum added the comment: I agree with Mark and Stafan. Hex/oct/bin are only defined for integers. __int__ is ambiguous -- it has the same problem as (int) in C in that it applies to floats and then loses the fraction. I think the problem with Ethan's ternary logic is that it

[issue19988] hex() and oct() use __index__ instead of __int__

Ethan Furman added the comment: For the record, the true/false values of my Logical type do convert to int, just not the unknown value. I agree using __int__ is dubious because of float (and Decimal, etc.), which means really the only clean way to solve the issue (definitely for me, and for

  1   2   >