list Integer indexing dies??
Dan Bishop
danb_83 at yahoo.com
Thu Dec 23 16:23:15 EST 2004
Jeff Shannon wrote:
> Ishwor wrote:
>
> >On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo
> ><FBatista at unifon.com.ar> 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
> 6 LOAD_CONST 1 (29)
> 9 STORE_FAST 1 (x)
>
> 12 SET_LINENO 3
> 15 LOAD_CONST 1 (29)
> 18 STORE_FAST 0 (y)
> 21 LOAD_CONST 0 (None)
> 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?
More information about the Python-list
mailing list