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

[HappyHippy]

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?'

comes out as "Hello World , how are you today?"

Have googled, and worked my way through the first 7 chapters of Byte of
Python, but to no avail...

TIA

HH

 

[Fredrik Lundh]

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?'

comes out as "Hello World , how are you today?"

Have googled, and worked my way through the first 7 chapters of Byte of
Python, but to no avail...

you can concatenate the strings before passing them to print:

text = 'Hello' + strName + ', how are you today?'
print text

or do the same on one line

print 'Hello' + strName + ', how are you today?'

or use string formatting (the % operator), or write to the special sys.stdout
file object (output to files is discussed in chapter 12).

</F>

 

[Alex Martelli]

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?'

comes out as "Hello World , how are you today?"

Have googled, and worked my way through the first 7 chapters of Byte of
Python, but to no avail...

Use string formatting:

print 'Hello %s, how are you today?' % strName


Alex

 

[Felipe Almeida Lessa]

Em Dom, 2006-02-12 às 22:11 +0000, HappyHippy escreveu:

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?'

comes out as "Hello World , how are you today?"

strname = 'World'
print 'Hello %s, how are you today?' % strname

--
"Quem excele em empregar a força militar subjulga os exércitos dos
outros povos sem travar batalha, toma cidades fortificadas dos outros
povos sem as atacar e destrói os estados dos outros povos sem lutas
prolongadas. Deve lutar sob o Céu com o propósito primordial da
'preservação'. Desse modo suas armas não se embotarão, e os ganhos
poderão ser preservados. Essa é a estratégia para planejar ofensivas."

-- Sun Tzu, em "A arte da guerra"

 

[bruno at modulix]

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.

 

[Rick Zantow]

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>

 

[Bruno Desthuilliers]

Rick Zantow a écrit :

<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