Force anything to be a string.

[Tim Peters]

[jonathon, finds that "str" has been rebound]
> ...
> 	A little poking around, and I found an object called
> 	str in two modules that the script calls.   After changing
> 	the name of those variables, that error disappeared.  :-)

This sounds like you fixed the symptom, but not the real cause:  it
shouldn't make any difference to *your* module what other modules happen to
name their variables.  Are you, by any chance, doing

from OtherModule import *

?  Then you're simply paying the price for being lazy <0.6 wink> -- that's
*inviting* OtherModule to stomp all over your names.  "import *" is a
convenience for interactive mode, and should almost never be used in a
script (there are a very few modules that were designed to be used that way,
but until you're a Python expert better to pretend it's illegal).

[Tim]
>> ... builtin function names are not reserved, which is both a feature
>> and a bug <0.7 [wink]>.


> 	A bug, IMNSHO.   A really bad bug, since I wasn't even using a
> 	module I wrote.

If you used "import *", you dug your own grave and so get no sympathy.  If
Python did reserve the builtin function names, then either (a) no builtin
function could ever be added to the language again; or, (b) adding a new
builtin function would break existing code that happened to use the same
name.  Neither is tolerable.  I'd like to see a warning msg, though (it
can't be made an error, at least not by default).

>> >>> str = 'oops'
>> >>> str(42)
>> Traceback (innermost last):
>>  File "<stdin>", line 1, in ?
>> TypeError: call of non-function (type string)
>> >>>
>>
>> The error msg there should look familiar.  It's telling you that the
>> syntax looks like a call, but the object in the caller's position *can't*
>> be called ("call of non-function"); and it's also giving the type of the
>> object that can't be called (str is of "type string").

> 	Another piece of wisdom to add to the list of things I
> 	couldn't find in _The Python Library Reference Manual_.

There are about 900 distinct error msgs in the Python implementation, and
while some of them could certainly be wordier, this one looks pretty darned
good to me!  I didn't explain it because I thought it was unclear, but to
nudge you into really *reading* the error msg and think about what it's
saying.  "call of non-function" doesn't have a heck of a lot of *possible*
meanings, after all <wink/frown>.

The "(type string)" part may be obscure (a disconnected sentence fragment)
the first time you see it, but playing around in interactive mode provoking
this msg quickly makes its meaning obvious.  It won't confuse you the 2nd
time you see it.

If the Python doc set contained a 450-page manual detailing every error msg
(figuring a half page per msg), would you have read it <0.9 wink>?

rhetorical-question-cuz-nobody's-gonna-write-that-anyway-ly y'rs  - tim