>>> dis.dis('pass')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dis.py", line 45, in dis
    disassemble_string(x)
  File "/usr/lib/python2.7/dis.py", line 112, in disassemble_string
    labels = findlabels(code)
  File "/usr/lib/python2.7/dis.py", line 166, in findlabels
    oparg = ord(code[i]) + ord(code[i+1])*256
IndexError: string index out of range

it happens for any string.

it happens that: (code, i) == ('pass', 4)

AFAIK dis.dis only decompiles bytecode in python 2, as is mentioned in the documentation at <http://docs.python.org/2/library/dis.html?highlight=dis#dis.dis>.  In Python 3 dis.dis can compile a string with Python source to bytecode and decompile that (see <http://docs.python.org/3/library/dis.html?highlight=dis#dis.dis>).

Thus this is IMHO not a bug.

Is it standard procedure to raise an unrelated exception in when an invalid parameter is passed? I did not encounter any other library function that behaves like this. Especially taking the fact that this is the normal usage in python3. 

How do I supposed to *know* this is not a bug? I can't find similar behavior in other library functions. An IndexError and a traceback *inside the library* does not help.

On 28 May, 2013, at 10:28, Elazar Gershuni <report@bugs.python.org> wrote:

> 
> Elazar Gershuni added the comment:
> 
> Is it standard procedure to raise an unrelated exception in when an invalid parameter is passed? I did not encounter any other library function that behaves like this. Especially taking the fact that this is the normal usage in python3. 

This is not the normal usage in python3, but one of the usecases supported in python3.  In python3 compiled code is a byte string and source code is a regular (unicode) string, which means the two can easily be recognized, while in python2 both are 'str' strings.

> 
> How do I supposed to *know* this is not a bug?

By reading the documentation? 

> I can't find similar behavior in other library functions. An IndexError and a traceback *inside the library* does not help.

Other library functions can also raise fairly obscure exceptions when you pass in bad data, as an example of this "os.path.join(None, 'a')" raises AttributeError.

If you pass 'None' for `path`, then "'NoneType' object has no attribute 'endswith'" is not as nearly as obscure.

But if you insist not to fix it, and don't mind to leave another arbitrary inconsistency between python2 and python3 obscured, I have nothing more to say - you can close it if you want.

Seconded Ronald. It's not a bug.

The automatic compilation of source code cannot be added to the 2.7 version of the dis module because that would be a new feature and we don't add new features in bugfix releases.  The feature was added to Python 3.x in issue #6507, and was first included in the 3.2 feature release.