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.
That depends on where you enter it. If you enter it in between a pair of
quotation marks, no conversion is done.
But I'll grant you that there are many places where the user/programmer
communicates to the Python interpreter, and can generally only do so via
characters or bytes. But that's hardly unique to numbers -- a dict is a
rich compound data structure, but you can only create dicts by entering
them as characters too. That's what we call syntax.
But the point is, once you have entered such a dict into the Python
virtual machine:
d = {'spam': lambda x: x**2 + 3*x - 5, 42: ['a', 'b', 23, object(), []],
17: (35, 19, True), 'x': {'cheese': 'cheddar'},
'y': {'animal': 'aardvark'}, 'z': None}
Python no longer needs to convert it or its components back and forth
between a string and the in-memory data structure. Converting to or from
strings tend to be used in only a very few places:
* compiling from source code, including eval and exec;
* the interactive interpreter;
* some, but not all, serialization formats (e.g. JSON and YAML);
* printing the object repr;
* explicitly converting to string;
which is a big win for both speed and memory. You'll note that every
single one of those is a special case of Input/Output.
[...]
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.
You are conflating lexing/parsing/compiling code with executing code.
Just because you need to have a plumber install your water pipes when
building a house, doesn't make it either practical or desirable to call a
plumber in every time you want to turn a tap on.
I will grant that there are situations where a more implicit type
conversion may be useful, or at least convenient. Perl does what you
want, promoting strings to ints (and visa versa?) depending on what you
try to do with them. Hypertalk, part of Apple's long defunct but not
forgotten Hypercard, was deliberately designed to help non-programmers
program. And I've sometimes experimented with config file formats that do
similar things. So it's not that I think that weak typing in the REXX/
Hypertalk/Perl sense is always wrong, only that it's wrong for Python.
On the other hand, both Flash and Javascript also do weak typing, and the
results in practice can be confusing and fraught with problems:
http://nedbatchelder.com/blog/200708/two_weak_typing_problems.html
And I think this quote from Peter Wone is amusing:
"Weak typing such as is used in COM Variants was an early attempt to
solve this problem, but it is fraught with peril and frankly causes more
trouble than it's worth. Even Visual Basic programmers, who will put up
with all sorts of rubbish, correctly pegged this as a bad idea and
backronymed Microsoft's ETC (Extended Type Conversion) to Evil Type Cast."
http://stackoverflow.com/questions/597664/when-should-weak-types-be-discouraged
It seems to me that weak typing is a Do What I Mean function, and DWIM is
a notoriously bad anti-pattern that causes far more trouble than it is
worth. I'm even a little suspicious of numeric coercions between integer
and float. (But only a little.)
