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