learnpython.org - an online interactive Python tutorial

[Steven D'Aprano]

On Sat, 23 Apr 2011 22:10:47 -0500, harrismh777 wrote:

>     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.)



-- 
Steven