Another n00b: Removing the space in "print 'text', var"

[Rick Zantow]

bruno at modulix <onurb at xiludom.gro> wrote in
news:43f05016$0$1408$626a54ce at news.free.fr: 

> HappyHippy wrote:
>> More of a minor niggle than anything but how would I remove the
>> aforementioned space?
> 
> 
>> eg.
>> strName = 'World'
>> print 'Hello', strName, ', how are you today?'
> 
> 
> Already got an anwser, now just a coding-style suggestion: hungarian
> notation is *evil*. And even *more* evil with a dynamically-typed
> language. 
> 

Bruno - 

<OT>
Although I agree with you in part (about the horror that is often called 
"Hungarian notation"), I would have to say that this particular use of 
it does not demonstrate that evil. What I consider bad about it is that 
people include an indication of datatype in the name, so that, say, the 
name of a C int would begin with the letter 'i'. The evil comes about 
when a different algorithm causes a change in the datatype of the 
variable (it is, for instance, redefined as a long, or a char), but the 
name itself does not change. From that point on, when encountering a 
variable whose name begins with 'i', it's not possible to be sure that 
it is an int, regardless of the coding convention involved. 

However, that is not how Hungarian notation was meant to be used. 
Instead, the prefix was to indicate the function of the variable, not 
its datatype. Thus, ctrXXX would be a counter (according to some 
hypothetical coding standard). If the datatype changed, the name would 
not have to change, as long as the variable's function remained the 
same.

In the HappyHippy example, the 'str' prefix does coincide with Python's 
indicator of a string class, as it happens. It is not clear that it need 
be more than coincidence, though. A string of bytes need not be of class 
str, and text need not be contained in a Python str, but the 'str' 
prefix could easily be attached to anything that indicated strung-
together data under some coding standard or another. Specifically, it 
wouldn't bother me greatly to discover that strXXX contained a normal 
Python string at some point and a Unicode string at another -- the 
function of strXXX would be the same in either case.

Dealing with the contents of strXXX might be a problem, of course, but 
that would also be true whenever the datatype of its contents could 
vary, regardless of its name. In a dynamic language, that variance could 
easily happen, which appears to be the basis for your "even *more* 
evil" comment. Appending a pseudotype prefix to an object's name doesn't 
fix the situation, but it doesn't really make it worse. A prefix of 
'str' should be enough to warn a maintainer not to assume the field is 
an accumulator or a function name, and maybe a little more than that, 
but in any event, in any language, the only sure way to know how an 
object is being used is to examine its context in the source. Anything 
naming convention (or comment, for that matter), is just dropping 
crystallized hints that are relavent to some particular moment in time. 
It is folly to assume they are necessarily still relevant.

Now it could be that I'm misinterpreting your objection to Hungarian 
notation. If so, I'd be interested in hearing what it is. Although I 
don't imagine any of this is actually on topic in the Python group.
</OT>

-- 
rzed