A Generated Python script Contains the code:
    if 1:
          file = bugreport.vim
          ... long list of commands ....

Executing this code with:
      exec cmds in globals(), globals()

Results in the error:
      SystemError: com_backpatch: offset too large

Looking into the code for com_backpatch() it appears
that the code is more than what can be jumped over.

Possible solutions:
1.  When there is too much code, use another jump
statement that allows for a larger offset.
2.  Always use a jump statement with a large offset
3.  When "if 1" is used, don't generate a jump
statement (not a real fix, but works for the situation
where I ran into the bug).

It looks like this bug exists in all versions of Python.

Logged In: YES 
user_id=6380

Just curious. How big was the block of code?

Also, I wonder if the error message is bogus; opcode
arguments can now be 32 bits AFAIK.

Logged In: YES 
user_id=6380

Hm, the 32-bit argument doesn't work because of what
backpatch does. It would require a totally different
approach to allow backpatching a larer offset, or we'd
always have to reserve 4 bytes for the offset. :-(

Logged In: YES 
user_id=57665

I can reproduce the problem with this text:
if 1:
   a = "a"

Repeat the assignment 7282 times.  Feed this text to "exec".
With 7281 assignments you do not get the error.
Looks like 9 bytes are produced per assignment.

Good luck fixing this!

Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

Logged In: YES 
user_id=752496

Can not reproduce the problem in Py2.3.4 using the method
posted by vimboss. It's already fixed?

Logged In: YES 
user_id=357491

I can't reproduce it with 2.3, 2.3 maintenance, 2.4 maintenance, or 2.5 in 
CVS using 8000 lines.

Closing as out of date.

Logged In: YES 
user_id=57665

It appears between Python 2.2 and 2.3 the efficiency of the
produced bytecode was improved.  You now need to repeat the
command 10923 times to produce the error.  Thus the problem
remains, it's just further away.

You can reproduce the problem with this program:
cmds = "if 1:\n"
for i in xrange(1, 10923):
    cmds = cmds + " a = 'a'\n"
exec cmds in globals(), globals()

I verified with Python 2.3.3, don't have a newer version
right now.

Logged In: YES 
user_id=752496

Also happens in 2.4.

I'm reopening the bug, in group 2.4.

Logged In: YES 
user_id=2772

Please see my (unsuitable for inclusion) patch at
http://mail.python.org/pipermail/python-list/2004-November/249827.html
I think that message suggests some steps that might result
in an acceptable patch.

Logged In: YES 
user_id=80475

Re-classifying this as a feature request for CPython
implementation to be expanded to handle larger relative
jumps.  The current behavior of raising a SystemError is
correct, non-buggy behavior.

One solution is to introduce a new bytecode for indirect
jumps based on an entry into the constants table.  Whenever
the distance is too large to backpatch a JUMP_FORWARD, that
opcode can be replaced with JUMP_INDIRECT and given an
offset into the constant table.  This solution is easy to
implement.  (Reminder, the peepholer should skip any code
containing the new opcode.)

#3 is already implemented. Note that there are some internal limits to the bytecode interpreter's code sizes etc., they can
be circumvented by putting the code in several functions and calling them in order.