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

[Bruno Desthuilliers]

Rick Zantow a écrit :
> bruno at modulix <onurb at xiludom.gro> wrote in
> news:43f05016$0$1408$626a54ce at news.free.fr: 
> 
> 
>>HappyHippy wrote:
>>
(snip)
>>>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. 
>>
> 
> <OT>
> Although I agree with you in part (about the horror that is often called 
> "Hungarian notation"), 
(snip)
> 
> 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. 

I know that. But:
1/ 99% of the developpers using (ms-perverted) hungarian notation ignore 
  this fact
2/ the name itself should be a clear enough indication of the [role, 
function, intended use] of the variable (<pedantic>well, of the object 
bound to that name in fact</pedantic>)
3/ see below...
4/ see below...

> Thus, ctrXXX would be a counter (according to some 
> hypothetical coding standard).

or a controller, according to some other hypothetical coding standard...

3/ prefixing (instead of suffixing) breaks readability.
compare :
- hit_counter
- hit_controller
- ctrHit

Which one do you find the most readable ? Clearly, prefixing (vs 
suffixing) puts things in the wrong order. And clearly, a three letters 
abbrev gives less information than a word.

(snip)

> In the HappyHippy example, the 'str' prefix does coincide with Python's 
> indicator of a string class, as it happens.

as it happens... cf /1

> It is not clear that it need 
> be more than coincidence, though. 

Which, given /1, is enough to confuse the situation. Ho, my, does this 
prefix means that it's supposed to be a string, or is it mere 
coïncidence ? And if so, what is this 'str' prefix supposed to mean ?

So much for readability...

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


4/ Well, I'm afraid that 'strung-together data' is more a type 
indication than a 'function' indication. And what should I say about 
byte string or Unicode...


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

Of course.

> Appending a pseudotype prefix to an object's name doesn't 
> fix the situation, but it doesn't really make it worse.

Yes it does. How do you like:

strAnswer += 42


> A prefix of 
> 'str' should be enough to warn a maintainer not to assume the field  is
> an accumulator or a function name,

A maintainer should not assume much IMHO. Heck, a function *name* is a 
string, isn't it ? And BTW, if, following some weird naming convention, 
the 'str' prefix was used to indicate 'strung-together-data', it could 
as well be used for any sequence(strung-together-data) - in which case 
it could be used for an accumulator !-)

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

So what's the use of prefixing it's name with distracting information ?

(snip)

> Now it could be that I'm misinterpreting your objection to Hungarian 
> notation. 

I'm afraid my objections to HN are nothing new.

> If so, I'd be interested in hearing what it is. 

Then you're done. To summarize:
- it's useless
- it's distracting
- it can be misleading
- it doesn't help readability

According to Python's zen:
- Beautiful is better than ugly.
- Readability counts.
- In the face of ambiguity, refuse the temptation to guess.

> Although I 
> don't imagine any of this is actually on topic in the Python group.

oops ! Sorry y'all

> </OT>