Velocity Reviews > Re: list Integer indexing dies??

# Re: list Integer indexing dies??

Ishwor
Guest
Posts: n/a

 12-23-2004
On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo
<(E-Mail Removed)> wrote:
>
>
> [Ishwor]
>
> #- > What should 035[0] cough up? Be carefull it should
> #-
> #- >>>035[0]
> #- 3 # my own opinion.

why 3? The reason we get 3 and not 0 here is the *fact* that Python
knows that its an octal rep. and not decimal
035[2] could return error here. Same for hex. No idea for binary. ~;-(

> #-
> #- > cough up the same as 29[0].
> #-
> #- >>>29[0]
> #- 2 #again my own opinion

since it's decimal its fine to get 2 which is at offset 0.

[snip]

--
cheers,
Ishwor Gurung

Jeff Shannon
Guest
Posts: n/a

 12-23-2004
Ishwor wrote:

>On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo
><(E-Mail Removed)> wrote:
>
>
>>[Ishwor]
>>
>>#- > What should 035[0] cough up? Be carefull it should
>>#-
>>#- >>>035[0]
>>#- 3 # my own opinion.
>>
>>

>why 3? The reason we get 3 and not 0 here is the *fact* that Python
>knows that its an octal rep. and not decimal
>
>

Except that, at the point where the indexing takes place, Python
*doesn't* know that it's an octal rep. All integer literals, regardless
of representation, generate exactly the same bytecode.

>>> def f():

.... x = 035
.... y = 29
....
>>> dis.dis(f)

0 SET_LINENO 1

3 SET_LINENO 2
9 STORE_FAST 1 (x)

12 SET_LINENO 3
18 STORE_FAST 0 (y)
24 RETURN_VALUE
>>>

Given that Python may not even have access to the .py file, only the
..pyc (which has lost all record of the source representation), there's
no way for the interpreter to do what you suggest.

Jeff Shannon
Technician/Programmer
Credit International

Dan Bishop
Guest
Posts: n/a

 12-23-2004
Jeff Shannon wrote:
> Ishwor wrote:
>
> >On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo
> ><(E-Mail Removed)> wrote:
> >
> >
> >>[Ishwor]
> >>
> >>#- > What should 035[0] cough up? Be carefull it should
> >>#-
> >>#- >>>035[0]
> >>#- 3 # my own opinion.
> >>
> >>

> >why 3? The reason we get 3 and not 0 here is the *fact* that Python
> >knows that its an octal rep. and not decimal
> >
> >

>
> Except that, at the point where the indexing takes place, Python
> *doesn't* know that it's an octal rep. All integer literals,

regardless
> of representation, generate exactly the same bytecode.
>
> >>> def f():

> ... x = 035
> ... y = 29
> ...
> >>> dis.dis(f)

> 0 SET_LINENO 1
>
> 3 SET_LINENO 2
> 9 STORE_FAST 1 (x)
>
> 12 SET_LINENO 3
> 18 STORE_FAST 0 (y)
> 24 RETURN_VALUE
> >>>

>
> Given that Python may not even have access to the .py file, only the
> .pyc (which has lost all record of the source representation),

there's
> no way for the interpreter to do what you suggest.

And even if there was, what should (104 + 0x68 + 0150)[0] print?