[Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__

[SourceForge.net]

Bugs item #660144, was opened at 2002-12-30 21:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Neil Schemenauer (nascheme)
Summary: typeobject provides incorrect __mul__

Initial Comment:
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__.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-01-26 22:58

Message:
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...

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2003-01-24 23:20

Message:
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.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-21 20:55

Message:
Logged In: YES 
user_id=6380

Looks like a good patch. And yes, the other types should be
doing this as well.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2003-01-19 20:35

Message:
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').

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-17 01:19

Message:
Logged In: YES 
user_id=6380

Yes, this should go into 2.3a2.

Your attachment upload failed somehow.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2003-01-17 00:10

Message:
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.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-16 22:57

Message:
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.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2003-01-16 22:33

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470