Help me understand this

[ArdPy]

Hi,

Pls tell me whats going on in the code snippet below:

>>n = 10
>>statstr = "N = ",n
>>type(statst r) #case1

<type 'tuple'>

>>print statstr

('N = ', 10)

>>print "N = ",n #case 2

N = 10

In the first case the result is printed as a tuple and in the second
it appears as an ordinary string.

[Steven D'Aprano]

Re: Help me understand this

On Mon, 29 Jan 2007 23:05:37 -0800, ArdPy wrote:

Hi,
>
Pls tell me whats going on in the code snippet below:
>

>>>n = 10
>>>statstr = "N = ",n
>>>type(statstr ) #case1

<type 'tuple'>

>>>print statstr

('N = ', 10)

>>>print "N = ",n #case 2

N = 10
>
In the first case the result is printed as a tuple and in the second
it appears as an ordinary string.

The print statement takes one or more comma-delimited objects, and prints
each one separated with a space, and then finally prints a newline. If you
end the list with a comma, no newline is printed. So when you execute the
line:

print "N = ", n

Python prints "N = ", then a space, then 10, then a newline.


Outside of a print statement (and also an "except" statement), commas
create tuples. So when you execute the line:

statstr = "N = ", n

the right-hand side is a tuple with two items. The first item is the
string "N = " and the second item is the integer currently named n (in
your case, 10).

Do not be fooled that brackets make tuples -- they don't. With the
exception of the empty tuple () which is a special case, it is commas that
make tuples. So these two lines have identical effects:

t = 1, 2, 3
t = (1, 2, 3)

That is why these two statements print something different:

print 1,2,3
print (1,2,3)

In the second case, the brackets force the expression "1,2,3" to be
evaluated before the print statement sees it, so the print statement sees
a single argument which is a tuple, instead of three int arguments.

(But notice that the brackets still aren't creating the tuple, the commas
are. The brackets just change the order of evaluation.)



--
Steven D'Aprano

[Beej]

Re: Help me understand this

On Jan 29, 11:47 pm, Steven D'Aprano
<s...@REMOVEME. cybersource.com .auwrote:

Outside of a print statement (and also an "except" statement), commas
create tuples.

And function calls:

>>3,

(3,)

>>type(3,)

<type 'int'>

>>type((3,))

<type 'tuple'>

But here's one I still don't get:

>>type(2)

<type 'int'>

>>type((2))

<type 'int'>

>>(2).__add__(1 )

3

>>2.__add__(1 )

File "<stdin>", line 1
2.__add__(1)
^
SyntaxError: invalid syntax

-Beej

[Diez B. Roggisch]

Re: Help me understand this

Beej wrote:

On Jan 29, 11:47 pm, Steven D'Aprano
<s...@REMOVEME. cybersource.com .auwrote:

>Outside of a print statement (and also an "except" statement), commas
>create tuples.

>
And function calls:
>

>>>3,

(3,)

>>>type(3,)

<type 'int'>

>>>type((3,))

<type 'tuple'>
>
But here's one I still don't get:
>

>>>type(2)

<type 'int'>

>>>type((2))

<type 'int'>

>>>(2).__add__( 1)

3

>>>2.__add__( 1)

File "<stdin>", line 1
2.__add__(1)
^
SyntaxError: invalid syntax

Because 2. is the start of a float-literal. That isn't distinguishable for
the parsere otherwise.


Diez

[James Stroud]

Re: Help me understand this

Beej wrote:

>>>(2).__add__( 1)

Nice. I would have never thought to put parentheses around an integer to
get at its attributes.

James

[Gabriel Genellina]

Re: Help me understand this

En Tue, 30 Jan 2007 06:34:01 -0300, Beej <beej@beej.uses cribió:

But here's one I still don't get:
>

>>>type(2)

<type 'int'>

>>>type((2))

<type 'int'>

>>>(2).__add__( 1)

3

>>>2.__add__( 1)

File "<stdin>", line 1
2.__add__(1)
^
SyntaxError: invalid syntax

It appears to be a bug, either in the grammar implementation, or in the
grammar documentation.
These are the relevant rules:

attributeref ::= primary "." identifier

primary ::= atom | attributeref | subscription | slicing | call

atom ::= identifier | literal | enclosure

literal ::= stringliteral | integer | longinteger | floatnumber |
imagnumber

An integer is a primary so 2.__add(1) should be valid.

--
Gabriel Genellina

[Neil Cerutti]

Re: Help me understand this

On 2007-01-30, Gabriel Genellina <gagsl-py@yahoo.com.ar wrote:

En Tue, 30 Jan 2007 06:34:01 -0300, Beej <beej@beej.uses cribió:
>

>But here's one I still don't get:
>>

>>>>type(2)

><type 'int'>

>>>>type((2))

><type 'int'>

>>>>(2).__add__ (1)

>3

>>>>2.__add__(1 )

> File "<stdin>", line 1
> 2.__add__(1)
> ^
>SyntaxError: invalid syntax

>
It appears to be a bug, either in the grammar implementation, or in the
grammar documentation.
These are the relevant rules:
>
attributeref ::= primary "." identifier
>
primary ::= atom | attributeref | subscription | slicing | call
>
atom ::= identifier | literal | enclosure
>
literal ::= stringliteral | integer | longinteger | floatnumber |
imagnumber
>
An integer is a primary so 2.__add(1) should be valid.

Not if the tokenizer passes the parser a float.

--
Neil Cerutti

[Beej]

Re: Help me understand this

On Jan 30, 1:38 am, "Diez B. Roggisch" <d...@nospam.we b.dewrote:

Because 2. is the start of a float-literal. That isn't distinguishable for
the parsere otherwise.

Oh, excellent! I wonder why I didn't think of that--I was too busy in
"get a field" mode it didn't even occur to me that the "." had a
different context, no matter how much more obvious.

>>print 2.

2.0

>>type(2.)

<type 'float'>

-Beej

[Christophe]

Re: Help me understand this

James Stroud a écrit :

Beej wrote:

>>>>(2).__add__ (1)

>
Nice. I would have never thought to put parentheses around an integer to
get at its attributes.
>
James

You can also do it like that :

>>2 .__add__(1)

3