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

2021-12-09 Thread Calin Culianu


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 as to what 
problems in particular, and how this change fixes those problems.

Mathematically, and by convention in computer science, conversions from 
float-like types -> int are always well defined.  It seems strangely 
un-Pythonic to restrict things in such a way.  I am very surprised by this 
change, quite frankly.  It's the wrong direction to go in, for this language, 
is my intuitive feeling.

Anyway, very curious about what the rationale was for this. Thanks.

--
nosy: +calin.culianu

___
Python tracker 
<https://bugs.python.org/issue36048>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2021-12-09 Thread Calin Culianu


Calin Culianu  added the comment:

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.

--

___
Python tracker 
<https://bugs.python.org/issue36048>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2021-12-09 Thread Calin Culianu


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 the 
actual problem, which was taken as a given in all the archaeology I have done 
on this ancient "issue" -- but is it a given?  There is no problem... only the 
one created by this change, really.

--

___
Python tracker 
<https://bugs.python.org/issue36048>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com