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
--
http://mail.python.org/mailman/listinfo/python-list
