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.

classification
Title: typeobject provides incorrect __mul__
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: nascheme Nosy List: gvanrossum, jackjansen, nascheme
Priority: normal Keywords:

Created on 2002-12-30 20:29 by nascheme, last changed 2022-04-10 16:06 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
getargs_int.diff nascheme, 2003-01-19 19:35 Disallow float for 'i' and 'l' types
getargs_int_warn.diff nascheme, 2003-01-27 05:57
Messages (12)
msg13728 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2002-12-30 20:29
type __mul__ is wierd:

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

Floating point numbers with fractions should not be
accepted.
I think the problem is that __mul__ should not be trying to
implement sq_repeat behavior (although I haven't dug
deeply into this problem yet).  Also, I think the code is
vulnerable to integer overflow.

Should also check __imul__ __add__ __iadd__.
msg13729 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-01-16 21:33
Logged In: YES 
user_id=35752

I think the problem is that wrap_intargfunc and
wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). 
This bug also is present in methods like __getitem__:

>>> "Python"[1.2]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: sequence index must be integer
>>> "Python".__getitem__(1.2)
'y'

I think the right fix is to use explictly only allow only
ints and longs to wrap_intargfunc and friends.  If Guido
agrees I will cook up a patch.  It seems like we should have
a code for PyParse_Tuple that only allows ints and longs.
msg13730 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-01-16 21:57
Logged In: YES 
user_id=6380

This is an age-old problem that crops up whenever "i" and
similar format codes are used.

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.

I think the "i" format code has to be fixe, but I'm not sure
how -- maybe as a start it would be sufficient to test
explicitly for float and its subclasses and reject those.
That would still allow 3rd party float-ish classes that
implement __int__, but that's not so important.
msg13731 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-01-16 23:10
Logged In: YES 
user_id=35752

Would this be a change for the 2.3 release?  I tried adding
a PyFloat_Check
test to 'i' and 'l' in getargs.c.  It looks like all the
unit tests pass.  I agree that
checking for float catches the important cases.

msg13732 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-01-17 00:19
Logged In: YES 
user_id=6380

Yes, this should go into 2.3a2.

Your attachment upload failed somehow.
msg13733 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-01-19 19:35
Logged In: YES 
user_id=35752

The small patch is attached.  I only added the checking for
'i' and 'l'.  I wonder if it should be done for the other
integer codes as well (e.g. 'b', 'h').
msg13734 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-01-21 19:55
Logged In: YES 
user_id=6380

Looks like a good patch. And yes, the other types should be
doing this as well.
msg13735 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-01-24 22:20
Logged In: YES 
user_id=35752

I added the check for the other integer codes.  All the
tests pass
so I checked it in.  Hope that's okay.
msg13736 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2003-01-26 21:58
Logged In: YES 
user_id=45365

Neil,
your mod to PyArg_Parse is far too aggressive. Apparently the integer formats have accepted floating point arguments since day one, and all weekend I'm running across places where floats are passed to integers. For example, the MacPython IDE does this all the time, and I wouldn't be surprised if there's lots of windowing code that does this (compute pixel positions in floating point and then passing them to something expecting an integer).

If this is fixed in this way (disallowing floats where integers are expected) it should at least be done with a DeprecationWarning for one release cycle. I think the fix probably is a good idea in the long run, but it will break large bodies of code...
msg13737 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-01-27 05:57
Logged In: YES 
user_id=35752

Attached is a patch that signals a DepreciationWarning
instead of rasing a TypeError.  I used a static function to
avoid duplication of code.  My version of GCC inlines it.
msg13738 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-02-03 22:15
Logged In: YES 
user_id=6380

Loosk good -- please check it in. Probably requires
something in NEWS too.
msg13739 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-02-04 21:02
Logged In: YES 
user_id=35752

Checked in as getargs.c 2.96 with NEWS.
History
Date User Action Args
2022-04-10 16:06:04adminsetgithub: 37666
2002-12-30 20:29:19naschemecreate