Bug or feature: double strings as one

[durumdara]

Hi!

I found an interesting thing in Python.
Today one of my "def"s got wrong result.

When I checked the code I saw that I miss a "," from the list.

l = ['ó' 'Ó']

Interesting, that Python handle them as one string.

print ['ó' 'Ó']
['\xf3\xd3']

I wanna ask that is a bug or is it a feature?

In other languages, like Delphi (Pascal), Javascript, SQL, etc., I
must concatenate the strings with some sign, like "+" or "||".

This technic is avoid the mistyping, like today. But in python I can
miss the concat sign, and I got wrong result...

Thanks for your help and for your answer:
dd

 

[Diez B. Roggisch]

Hi!

I found an interesting thing in Python.
Today one of my "def"s got wrong result.

When I checked the code I saw that I miss a "," from the list.

l = ['ó' 'Ó']

Interesting, that Python handle them as one string.

print ['ó' 'Ó']
['\xf3\xd3']

I wanna ask that is a bug or is it a feature?

In other languages, like Delphi (Pascal), Javascript, SQL, etc., I
must concatenate the strings with some sign, like "+" or "||".

This technic is avoid the mistyping, like today. But in python I can
miss the concat sign, and I got wrong result...

It's a feature. It is sometimes used in cases where you want to split a
longer text into several lines, but without introducing newlines.

like this (the parentheses are there for the parser not to puke):


foo = ("foobarbaz"
"padamm")

It has the potential to produce errors as you have seen them, though.

Diez

 

[Peter Otten]

I found an interesting thing in Python.
Today one of my "def"s got wrong result.

When I checked the code I saw that I miss a "," from the list.

l = ['ó' 'Ó']

Interesting, that Python handle them as one string.

print ['ó' 'Ó']
['\xf3\xd3']

I wanna ask that is a bug or is it a feature?

Feature:

http://docs.python.org/reference/lexical_analysis.html#string-literal-concatenation

Peter

 

[kj]

durumdara wrote:

I found an interesting thing in Python.
Today one of my "def"s got wrong result.

When I checked the code I saw that I miss a "," from the list.

l = ['ó' 'Ó']

Interesting, that Python handle them as one string.

print ['ó' 'Ó']
['\xf3\xd3']

I wanna ask that is a bug or is it a feature?

Feature, as others have pointed out, though I fail to see the need
for it, given that Python's general syntax for string (as opposed
to string literal) concatenation is already so convenient. I.e.,
I fail to see why

x = ("first part of a very long string "
"second part of a very long string")

is so much better than

x = ("first part of a very long string " +
"second part of a very long string")

FWIW, C has the same concatenation feature for string literals.
E.g., the following is valid C:

printf("first part of a very long string "
"second part of a very long string\n");

kynn

 

[alex23]

Feature, as others have pointed out, though I fail to see the need
for it, given that Python's general syntax for string (as opposed
to string literal) concatenation is already so convenient.  I.e.,
I fail to see why

x = ("first part of a very long string "
     "second part of a very long string")

is so much better than

x = ("first part of a very long string " +
     "second part of a very long string")

My impression is it's mostly for one of clarity. It's especially
useful with regular expressions, as it allows for comments to document
each element of the regex (following example shamelessly taken from
the docs (albeit with personal preferences on formatting))):

re.compile(
"[A-Za-z_]" # letter or underscore
"[A-Za-z0-9_]*" # letter, digit or underscore
)

Not having the plus sign present does assist (IMO) in the ease of
parsing the regex.
re.compile(

 

[Bearophile]

durumdara:

I wanna ask that is a bug or is it a feature?

For me it's a bug-prone antifeature.

Bye,
bearophile

 

[John Machin]

Feature, as others have pointed out, though I fail to see the need
for it, given that Python's general syntax for string (as opposed
to string literal) concatenation is already so convenient.  I.e.,
I fail to see why

x = ("first part of a very long string "
     "second part of a very long string")

is so much better than

x = ("first part of a very long string " +
     "second part of a very long string")

My impression is it's mostly for one of clarity. It's especially
useful with regular expressions, as it allows for comments to document
each element of the regex (following example shamelessly taken from
the docs (albeit with personal preferences on formatting))):

re.compile(
    "[A-Za-z_]"       # letter or underscore
    "[A-Za-z0-9_]*"   # letter, digit or underscore
)

Not having the plus sign present does assist (IMO) in the ease of
parsing the regex.
re.compile(

re.VERBOSE?

 

[r]

Hi!

I found an interesting thing in Python.
Today one of my "def"s got wrong result.

....(snip)

I think it's a completely useless feature and i have never used it
even once! This so-called "feature" seems a direct contridiction to
the zen...

"""There should be one-- and preferably only one --obvious way to do
it. """

 

[r]

It sure doesn't get any more obivous than...
"string1" + "string2"

Although i much prefer string formatting to concatenation for almost
all cases except the most simple. This auto-magic conacatenation of
strings is unintuitive and completely moronic if you ask my opinion. I
blow chunks when i see this type of code, and the result from it, and
so should my interpretor!
"string1" "string2" --> syntax error you moron!

If you are wanting to create shortcuts, do them where they make sense
and can serve a useful purpose...

t = ('1' "word" 33.3)
l = [1 2 3 (4 5)]
d = {keyname:value keyname:value etc...}

KISS people!

 

[Steven D'Aprano]

I fail to see why

x = ("first part of a very long string "
"second part of a very long string")

That's done by the compiler at compile time and is fast.

is so much better than

x = ("first part of a very long string " +
"second part of a very long string")

That's done by the Python virtual machine at runtime and creates two
strings, then passes them to a method, which creates a third string, then
(usually) disposes of the first two strings.

Except for some versions of the CPython implementation, which has a
keyhole compiler which folds constants at runtime. But it's a simple
optimizer, easy to defeat:
1 0 LOAD_CONST 0 ('')
3 STORE_NAME 0 (s)
6 LOAD_NAME 0 (s)
9 LOAD_CONST 1 ('a')
12 BINARY_ADD
13 LOAD_CONST 2 ('b')
16 BINARY_ADD
17 POP_TOP
18 LOAD_CONST 3 (None)
21 RETURN_VALUE 1 0 LOAD_CONST 0 ('')
3 STORE_NAME 0 (s)
6 LOAD_NAME 0 (s)
9 LOAD_CONST 1 ('ab')
12 BINARY_ADD
13 POP_TOP
14 LOAD_CONST 2 (None)
17 RETURN_VALUE

 

[r]

On Aug 7, 10:31 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
....(snip excessive showmanship)

Ah Steven thats a real nice "snappy comeback" and some may get blinded
by the "black magic" but basically all you are saying is that "version
a" takes less overhead than "version b", compilation wise... but let's
dig a little deeper shall we?

First of all, i don't know about you but i don't set around all day
hard coding string data into my programs so the nano second difference
gained between auto-magic-string-concatination and "s1"+"s2"+"sN"
really doesn't justify a feature(bug??) like this that breaks the Zen
wide open. Sadly all it serves is to confuse new comers and contribute
line noise to the tutorial -- of which there is too much already!

Sure it's a nice parlor trick, but not much more...

Q: Steven, how often do you actually use this feature, i mean *really*
use it?

 

[Carl Banks]

Definitely.  Not only does it have _all_ the features, it even
manages to simultaneously have several mutually-exclusive
features.

http://www.geocities.com/connorbd/tarpit/magentaaarm.html


(It's on Geocities, yikes, someone better archive that....)

Carl Banks

 

[Mark Lawrence]

Definitely. Not only does it have _all_ the features, it even
manages to simultaneously have several mutually-exclusive
features.

I have tried google for this "etc." language but failed dismally. Does
it belong here? http://www.thefreecountry.com/compilers/esoteric.shtml

 

[Jan Kaliszewski]

That's done by the compiler at compile time and is fast.

Moreover, it's also more readable, when you use str calling its
methods or using formatting on it.

I use it very often, e.g.:

afunction('quite long string %s quite long string '
'quite long string quite long string %s '
'quite %s long string quite long string'
% (variable1, variable2, variable3))

It seems nicer to me than:

afunction(('quite long string %s quite long string '
+ 'quite long string quite long string %s '
+ 'quite %s long string quite long string')
% (variable1, variable2, variable3))

(Note that multiline-'''-strings are usless in such cases).

*j

 

[r]

I use it very often, e.g.:

         afunction('quite long string %s quite long string '
                   'quite long string quite long string %s '
                   'quite %s long string quite long string'
                   % (variable1, variable2, variable3))

It seems nicer to me than:

         afunction(('quite long string %s quite long string '
                    + 'quite long string quite long string %s '
                    + 'quite %s long string quite long string')
                   % (variable1, variable2, variable3))

(Note that multiline-'''-strings are usless in such cases).

uhh? A much better way to handle such a problem is like this...

prompt1 = '''
Some people like to use %s
ways of doing things just
so they can support their %s
way of coding
'''

afunction(prompt1 %(var1, var2))

WOW!, that just somehow looks more professional to me? I hate to long
strings in the middle of a code block. Please be smart when writing
code people!!

 

[Anny Mous]

uhh? A much better way to handle such a problem is like this...

prompt1 = '''
Some people like to use %s
ways of doing things just
so they can support their %s
way of coding
'''

Oh wow, you so need to work on your reading comprehension skills! Didn't you
notice Jan's comment that multiline ''' strings are useless??? They add
extra newlines into the string which aren't wanted.

WOW!, that just somehow looks more professional to me? I hate to long
strings in the middle of a code block. Please be smart when writing
code people!!

Because totally failing to pay attention to the requirements is "smart".

 

[Jan Kaliszewski]

uhh? A much better way to handle such a problem is like this...

prompt1 = '''
Some people like to use %s
ways of doing things just
so they can support their %s
way of coding
'''

Sorry, you are wrong, '''-way would be usefull only if:

* you want to have '\n' in each place where you wrap the
literal in your code,

and

* you use '''-literal at a module (non-indented) level

or you need not only '\n'-s but also indentations
(dependent on indentation of your code),

or such ugly indentation is ok for you:

some indentated code...
         prompt = '''quite long string %s quite long string
''' quite long string quite long string %s
''' quite %s long string quite long string
'''
some indentated code...


That's why I wrote it's "useless in such cases."

Regards,
*j

 

[r]

Sorry, you are wrong, '''-way would be usefull only if:

     * you want to have '\n' in each place where you wrap the
       literal in your code,

and

     * you use '''-literal at a module (non-indented) level

       or you need not only '\n'-s but also indentations
          (dependent on indentation of your code),

       or such ugly indentation is ok for you:

           some indentated code...
           prompt = '''quite long string %s quite long string
''' quite long string quite long string %s
''' quite %s long string quite long string
'''
           some indentated code...

That's why I wrote it's "useless in such cases."

@ Jan & Anny

No, of course putting a multi-line string inside a block does not
solve anything. What i meant for you to do is to declare the string
outside the block or as a module level Constant. i typically declare
all multi-line strings (ig for dialog prompts etc..) right after my
globals at the top of my modules or within an imported module like...

from thisModuleConstants import *

 

[r]

#-- el bueno --#
"hello i am a very long string that\
does not like newlines so please \
escape me, Thank you!"

#-- el malo --#
"hello i am a very long string that"+
"does not like newlines but i have no"+
"idea what to do with myself"

#-- el feo --#
"hello i am a very long string that"
"does not like newlines but i have no"
"idea what to do with myself"


just ideas people!

 

[Jan Kaliszewski]

#-- el bueno --#
"hello i am a very long string that\
does not like newlines so please \
escape me, Thank you!"

You probably ment: """hello i am... [etc.]

Anyway... You're right that generally it's good idea to define
dialog prompts and such stuff separately rather that to hardcode
it, especially in big projects. Then certainly multiline
string literals are useful (though, if you need to get rid of
newlines, IMHO "el feo" method is more elegant and less error
prone than your "el bueno" [possible invisible space after '\']).

But there are plenty of other situations when it's better
(in practice) to have strings (even long) together with your
code, e.g. log information for debugging, or

Cheers,

*j