Steven D'Aprano wrote:
If that's a "serious" flaw, it's a flaw shared by the vast majority of programming languages.
Yes, agreed.
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.
I see your point... but I'll push back just a little, in a minute...
Consider... "one" + 1 "[1, 2, 3]" + [4] "[2, 40, 10, 3]".sort()
Yes, maybe problems all. Again, I see the point of your argument, and I do not necessarily disagree...
I've been giving this some more thought. From the keyboard, all I am able to enter are character strings (not numbers). Presumably these are UTF-8 strings in python3. If I enter the character string 57 then python converts my character string input and returns an reference to object 57. If I enter the keyboard character string 34567 then the python interpreter converts my character string input into an object (creates a new object) (34567) returning a reference to that object (a type int). If I enter the keyboard character string 3.14 the python interpreter creates a float object (converts my string into a float) and returns a reference to the object. In any event, keyboard character strings that just happen to be numbers, are converted into int or float objects by the interpreter, from the keyboard, automatically. My idea for consistency is this: since the interpreter converts int to float, and float to imaginary (when needed), then it does (at least in a limited way) type promoting. So, it is consistent with the input methods generally to promote numeric string input to int --> float --> imaginary, as needed, therefore it is also consistent to promote a numeric string (that which I used to call a REXX number) into an int --> float --> imaginary, as implied by the statement(s). I am not asking for weak typing generally... nor am I thinking that all promotions are a good thing... just numeric string to int --> float --> imaginary when it makes sense. In any event, the programmer should be able to overide the behavior explicitly. On the other hand, I do see your point regarding performance. Otherwise,...
... type promotions really would not cause any more confusion for programmers who now know that int will be converted to float and use that knowledge conveniently....
I do believe that explicit is better than implicit (generally)... but not in this case. I am noticing a pattern in some of the responses, and that pattern is that some folks would find this appealing if not overtly convenient. The question IS, which I am not able to answer at this point, whether the convenience would actually cause other difficulties that would be worse...?
kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
