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.

Author calin.culianu
Recipients arhadthedev, calin.culianu, gvanrossum, hroncok, mark.dickinson, remi.lapeyre, serhiy.storchaka, vstinner
Date 2021-12-09.18:51:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1639075919.64.0.665666609967.issue36048@roundup.psfhosted.org>
In-reply-to
Content
Ok, well I found this in that issue you linked to:

This is the original "problem":

```
type __mul__ is wierd:

>> 'a'.__mul__(3.4)
'aaa'
>>> [1].__mul__(3.4)
[1, 1, 1]
```

And this is Guido's response:

> The problem is that on the one hand you want "i" to accept
other int-ish types that have an __int__ method. But on the
other hand you don't want it to accept float, which also has
an __int__ method. Or other float-ish types.

--- 

You have to understand -- I don't see a problem here!

Not once is there any discussion as to *why* this is really a problem. So what? Your float gets truncated and treated as an int.  So?

If you are calling into a C api -- why is this a problem exactly when **in the C Language itself** by convention and by compiler rules anyway -- this is **perfectly ok**.

Restricting Python in this way -- why? What is the benefit? What problem is being solved? I did all the digging in the world here and cannot at all discern what, exactly, is being solved at all.  It seems like some bizarre aesthetic thing, at best.  Sorry.. maybe I am wrong.  Please point me to where the real problem is... 

Again, I reiterate **mathematically**, by convention in computer science, the conversion from float -> int is well defined.  Moreover, you have the legacy __int__ method already that *can define it* for specific types. And Python has worked this way since the age of the dinosaurs (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** it's a problem!

This boggles my mind, guys. I.. am speechless.  Please tell me I'm wrong. To me it seems you guys imagined a problem that doesn't exist, then "solved" it with extra API stuff, and the actual end result was -- real-world problems created ex-nihilo for real-world programs, manifesting themselves finally in 2021.

You have to understand that .. to me as a C++ programmer.. I see no problem. I just see Python all of a sudden becoming less nice.
History
Date User Action Args
2021-12-09 18:51:59calin.culianusetrecipients: + calin.culianu, gvanrossum, mark.dickinson, vstinner, serhiy.storchaka, hroncok, remi.lapeyre, arhadthedev
2021-12-09 18:51:59calin.culianusetmessageid: <1639075919.64.0.665666609967.issue36048@roundup.psfhosted.org>
2021-12-09 18:51:59calin.culianulinkissue36048 messages
2021-12-09 18:51:59calin.culianucreate