«

# is the difference between
print(" %d, %d, buckle my shoe" % (1,2))
# and
print(" %d, " + " %d, buckle my shoe" % (1,2))
# a bug or a feature?

First output
.... print(" %d " + " %d, buckle my shoe" % (1,2))

Second output
TypeError: not all arguments converted during string formatting

Version Info:
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2

also

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on win32

#whoops, the first output is actually

1, 2, buckle my shoe

# in case it wasn't obvious


On Mar 16, 5:00*pm, bdb112 <boyd.blackw...@gmail.com> wrote:
> # * is the difference between
> print(" %d, *%d, buckle my shoe" % (1,2))
> # * and
> print(" %d, " + " %d, buckle my shoe" % (1,2))
> # a bug or a feature?
>
> First output
> ... print(" %d " + " %d, buckle my shoe" % (1,2))
>
> Second output
> TypeError: not all arguments converted during string formatting
>
> Version Info:
> Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
> [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
>
> also
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
> (Intel)] on win32

On Mar 16, 7:00*pm, bdb112 <boyd.blackw...@gmail.com> wrote:
> # * is the difference between
> print(" %d, *%d, buckle my shoe" % (1,2))
> # * and
> print(" %d, " + " %d, buckle my shoe" % (1,2))
> # a bug or a feature?

Here's a question for you:
Is the difference between
print(30 % 7)
and
print(10 + 20 % 7)
a bug or a feature?

Cheers,
John

> On Mar 16, 5:00Â*pm, bdb112 <boyd.blackw...@gmail.com> wrote:
> > # Â* is the difference between
> > print(" %d, Â*%d, buckle my shoe" % (1,2))
> > # Â* and
> > print(" %d, " + " %d, buckle my shoe" % (1,2))
> > # a bug or a feature?

It is correct behavior. On the other hand, it is one of the, well,
bugs, that is avoided by the 'format' method in 3.x.

--
R. David Murray http://www.bitdance.com

Thanks for all the replies:
I think I see now - % is a binary operator whose precedence rules are
shared with the modulo operator regardless of the nature of its
arguments, for language consistency.
I understand the arguments behind the format method, but hope that the
slightly idiosyncratic print( ..% ..) remains, as the vaguely
pictorial "printf" format string is clearer for a long line with
several arguments.
I will use the "implicit string concatenation" to solve my problem but
it is a little odd that an "invisible" operator is stronger than a
visible one. (+).

On Mar 16, 5:00*pm, bdb112 <boyd.blackw...@gmail.com> wrote:
> # * is the difference between
> print(" %d, *%d, buckle my shoe" % (1,2))
> # * and
> print(" %d, " + " %d, buckle my shoe" % (1,2))
> # a bug or a feature?
>
> First output
> ... print(" %d " + " %d, buckle my shoe" % (1,2))
>
> Second output
> TypeError: not all arguments converted during string formatting
>
> Version Info:
> Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
> [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
>
> also
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
> (Intel)] on win32

bdb112 wrote:
> Thanks for all the replies:
> I think I see now - % is a binary operator whose precedence rules are
> shared with the modulo operator regardless of the nature of its
> arguments, for language consistency.
> I understand the arguments behind the format method, but hope that the
> slightly idiosyncratic print( ..% ..) remains, as the vaguely
> pictorial "printf" format string is clearer for a long line with
> several arguments.
> I will use the "implicit string concatenation" to solve my problem but
> it is a little odd that an "invisible" operator is stronger than a
> visible one. (+).

The implicit string concatenation is actually done by the compiler; it
isn't an operator at all. Look:

>>> import dis
>>> def f():
.... return "foo" "bar"
....
>>> dis.dis(f)
2 0 LOAD_CONST 1 ('foobar')
3 RETURN_VALUE
--

On Mar 18, 4:19*pm, Matt Nordhoff <mnordh...@mattnordhoff.com> wrote:
> bdb112 wrote:
> > Thanks for all the replies:
> > I think I see now - % is a binary operator whose precedence rules are
> > shared with the modulo operator regardless of the nature of its
> > arguments, for language consistency.
> > I understand the arguments behind the format method, but hope that the
> > slightly idiosyncratic print( ..% ..) remains, as the vaguely
> > pictorial "printf" format string is clearer for a long line with
> > several arguments.
> > I will use the "implicit string concatenation" to solve my problem but
> > it is a little odd that an "invisible" operator is stronger than a
> > visible one. (+).
>
> The implicit string concatenation is actually done by the compiler; it
> isn't an operator at all. Look:
>
> >>> import dis
> >>> def f():
>
> ... * * return "foo" "bar"
> ...>>> dis.dis(f)
>
> * 2 * * * * * 0 LOAD_CONST * * * * * * * 1 ('foobar')
> * * * * * * * 3 RETURN_VALUE
> --

I think you need better evidence than that obtained by proctologising
about with dis.dis:

Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] onwin32
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> def f():
.... return ('foo') + ('bar')
....
>>> dis.dis(f)
2 0 LOAD_CONST 3 ('foobar')
3 RETURN_VALUE
>>>

Cheers,
John

On Tue, 17 Mar 2009 22:41:26 -0700, John Machin wrote:

> On Mar 18, 4:19Â*pm, Matt Nordhoff <mnordh...@mattnordhoff.com> wrote:

>> The implicit string concatenation is actually done by the compiler; it
>> isn't an operator at all. Look:
>>
>> >>> import dis
>> >>> def f():
>>
>> ... Â* Â* return "foo" "bar"
>> ...>>> dis.dis(f)
>>
>> Â* 2 Â* Â* Â* Â* Â* 0 LOAD_CONST Â* Â* Â* Â* Â* Â* Â* 1 ('foobar')
>> Â* Â* Â* Â* Â* Â* Â* 3 RETURN_VALUE
>> --
>
> I think you need better evidence than that obtained by proctologising
> about with dis.dis:
>
> Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
> (Intel)] onwin32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import dis
>>>> def f():
> ... return ('foo') + ('bar')
> ...
>>>> dis.dis(f)
> 2 0 LOAD_CONST 3 ('foobar')
> 3 RETURN_VALUE


That's the keyhole optimizer in action. It replaces operations on two
literals at compile-time whenever possible. By memory, that was
introduced by Python 2.4, and implicit string concatenation was
introduced way back in the mists of time. In Python 2.1 we have this:


>>> dis.dis(compile("'ab' 'cd'", '', 'single'))
0 SET_LINENO 0

3 SET_LINENO 1
6 LOAD_CONST 0 ('abcd')
9 PRINT_EXPR
10 LOAD_CONST 1 (None)
13 RETURN_VALUE
>>>
>>> dis.dis(compile("1+1", '', 'single'))
0 SET_LINENO 0

3 SET_LINENO 1
6 LOAD_CONST 0 (1)
9 LOAD_CONST 0 (1)
12 BINARY_ADD
13 PRINT_EXPR
14 LOAD_CONST 1 (None)
17 RETURN_VALUE



I suppose, technically, implicit string concatenation could happen inside
the lexer, or the parser, or some other process, but I think most people
are happy to simplify all of those as "the compiler". Whenever it
happens, the important thing is that it is *not* at runtime.



--
Steven