learnpython.org - an online interactive Python tutorial

[Steven D'Aprano]

On Fri, 22 Apr 2011 01:38:21 -0500, harrismh777 wrote:

> Heiko Wundram wrote:
>> The difference between strong typing and weak typing is best described
>> by:
>>
>> Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01) [GCC 4.3.4 20090804
>> (release) 1] on cygwin Type "help", "copyright", "credits" or "license"
>> for more information.
>>>>> >>>  1+'2'
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in<module>
>> TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>>>> >>>
>>>>> >>>
> Yes. And you have managed to point out a serious flaw in the overall
> logic and consistency of Python, IMHO.
> 
> Strings should auto-type-promote to numbers if appropriate.

If that's a "serious" flaw, it's a flaw shared by the vast majority of 
programming languages.

As for the question of "consistency", I would argue the opposite: that 
auto-promoting strings to numbers arguably is useful, but that is what is 
inconsistent, not the failure to do so.

Consider...

"one" + 1

Should this also promote "one" to integer 1? If so, what about "uno" and 
"un" and "ein" and "один"? 

If not, why privilege one *string* representation of the number 1 over 
other *string* representations of the number 1?

How about this?

"[1, 2, 3]" + [4]

Should that auto-promote to a list as well? If not, why not? Why does 
your argument in favour of auto-promotion to int also not apply to auto-
promotion to list?

What about this?

"[2, 40, 10, 3]".sort()

Should that auto-promote to list? Should the result of sorting be 
[2, 3, 10, 40] or ['10', '2', '3', '40']? 

What about:

"[2, 4, 1, 3]".index("[")

Should that call the *string* index method, or the *list* index method?


If you want to argue that auto-promoting of strings to numbers is 
convenient for lazy programmers who can't be bothered keeping the 
distinction between strings and numbers straight, or for those who can't 
base the extra typing required to call int() but don't mind the 
inefficiency of the language repeatedly converting numbers to and from 
strings in the background, then I'd agree that the "convenience" argument 
is an argument in favour of weak-typing. (Not necessarily a *good* 
argument, but it's an argument.)

But I hope it is clear that "consistency" is not an argument in favour of 
weak-typing. As far as I know, no language applies weak-typing broadly to 
all types, and if a language did, it would be fraught with problems and 
traps.


[...]
> My feelings about this are strongly influenced by my experiences with
> the REXX language on IBM's SAA systems--- OS/2 and VM/CMS. In REXX
> everything is a string... everything. 

This is much like my experience with Apple's Hypertalk, where the only 
data structure is a string. I'm very fond of Hypertalk, but it is hardly 
designed with machine efficiency in mind. If you think Python is slow 
now, imagine how slow it would be if every expression had to be converted 
from a number back into a string, and vice versa, after every operation:

x = str(int("1") + int("2"))
y = str(int("9")/int("3"))
z = str(int(x) - int(y))
flag = str(int(z) == int("0"))

only implicitly, by the interpreter.


-- 
Steven