Bug or feature: double strings as one
durumdara
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.
>
>
> Interesting, that Python handle them as one string.
>
> ['\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
Grant Edwards
> 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.
>
>
> Interesting, that Python handle them as one string.
>
> ['\xf3\xd3']
>
> I wanna ask that is a bug or is it a feature?
You "wanna"?
> In other languages, like Delphi (Pascal), Javascript, SQL, etc., I
> must concatenate the strings with some sign, like "+" or "||".
In other languages like Ruby, awk, C, C++, etc. adjacent string
constants are concatenated.
--
Grant Edwards grante Yow! Is it clean in other
at dimensions?
visi.com
Scott David Daniels
> On 2009-08-07, durumdara <duru...@gmail.com> wrote:
>> In other languages, like Delphi (Pascal), Javascript, SQL, etc., I
>> must concatenate the strings with some sign, like "+" or "||".
>
> In other languages like Ruby, awk, C, C++, etc. adjacent string
> constants are concatenated.
I must learn this "etc." language, I hear it mentioned all the time :-)
--Scott David Daniels
Scott....@Acm.Org
Grant Edwards
Definitely. Not only does it have _all_ the features, it even
manages to simultaneously have several mutually-exclusive
features.
--
Grant Edwards grante Yow! I'm meditating on
at the FORMALDEHYDE and the
visi.com ASBESTOS leaking into my
PERSONAL SPACE!!
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(
Duncan Booth
> Definitely. Not only does it have _all_ the features, it even
> manages to simultaneously have several mutually-exclusive
> features.
Sounds a bit like Perl.
Bearophile
> I wanna ask that is a bug or is it a feature?
For me it's a bug-prone antifeature.
Bye,
bearophile
John Machin
re.VERBOSE?
r
> Hi!
>
> I found an interesting thing in Python.
> Today one of my "def"s got wrong result.
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
"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:
>>> import dis
>>> dis.dis(compile("s = ''; s + 'a' + 'b'", '', 'exec'))
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
>>>
>>> dis.dis(compile("s = ''; s + 'a' 'b'", '', 'exec'))
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
--
Steven
r
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
> On 2009-08-07, Scott David Daniels <Scott.Dani...@Acm.Org> wrote:
>
> > Grant Edwards wrote:
> >>> In other languages, like Delphi (Pascal), Javascript, SQL, etc., I
> >>> must concatenate the strings with some sign, like "+" or "||".
>
> >> In other languages like Ruby, awk, C, C++, etc. adjacent string
> >> constants are concatenated.
>
> > I must learn this "etc." language, I hear it mentioned all the time :-)
>
> 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
> On 2009-08-07, Scott David Daniels <Scott....@Acm.Org> wrote:
>> Grant Edwards wrote:
>>> On 2009-08-07, durumdara <duru...@gmail.com> wrote:
>>>> In other languages, like Delphi (Pascal), Javascript, SQL, etc., I
>>>> must concatenate the strings with some sign, like "+" or "||".
>>> In other languages like Ruby, awk, C, C++, etc. adjacent string
>>> constants are concatenated.
>> I must learn this "etc." language, I hear it mentioned all the time :-)
>
> Definitely. Not only does it have _all_ the features, it even
> manages to simultaneously have several mutually-exclusive
> features.
>
it belong here? http://www.thefreecountry.com/compilers/esoteric.shtml
--
Kindest regards.
Mark Lawrence.
Elias Fotinis (eliasf)
> http://www.geocities.com/connorbd/tarpit/magentaaarm.html
> (It's on Geocities, yikes, someone better archive that....)
http://web.archive.org/web/*/http://www.geocities.com/connorbd/tarpit/magentaaarm.html
:)
Jan Kaliszewski
> On Fri, 07 Aug 2009 17:35:28 +0000, kj wrote:
>
>> 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.
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
--
Jan Kaliszewski (zuo) <z...@chopin.edu.pl>
r
> 08-08-2009 Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote:
> 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
> On Aug 8, 12:43 pm, "Jan Kaliszewski" <z...@chopin.edu.pl> wrote:
>> (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
> '''
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
> On Aug 8, 12:43 pm, "Jan Kaliszewski" <z...@chopin.edu.pl> wrote:
>> 08-08-2009 Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote:
> ...(snip)
>> 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
> '''
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,
r
..(snip)
> 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
MRAB
>> "hello i am a very long string that\
>> does not like newlines so please \
>> escape me, Thank you!"
>
>
> 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
>
A string prefixed with 'i' would be an 'indented' string. Leading space
and tab characters at the start of the string (just after the quote) or
the start of each line within a multiline string would be ignored.
>>> """Line 1
Line 2
"""
'Line 1\n Line 2\n'
>>> i"""Line 1
Line 2
"""
'Line 1\nLine 2\n'
An additional feature could be to make '\ ' == ' ', perhaps only for
indented strings if you're worried that it could breaking existing code:
>>> i"""Line 1
\ Line 2
"""
'Line 1\n Line 2\n'
This would save you having to write '\x20'.