list Integer indexing dies??

Dan Bishop danb_83 at yahoo.com
Thu Dec 23 22:23:15 CET 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