Glad there was such a simple fix. :-)

Thanks!  That's great.

While trying to address this, I found some old Python 2.5 compatibility code in
translate.py and got rid of it since we don't support Python 2.5 any more anyway
(as you saw). Without this compatibility code, you should get a syntax error in
Python 2.5, too. (I hope -- I cannot test this.)

I hope this resolves the issue? If not, please reopen.

Getting a syntax error with 2.4 seems fine, since it's likely to point to the 
real problem (too-old python).  The real challenge is with 2.5 where you don't 
get an error until runtime, and that error is unhelpful.

For a pre-check, I would suggest (1), since it's an opportunity to give the user 
a head's up at the time when s/he is installing the software.

2 and 3 seemed less good to me, since I have been driven by the wiki, which 
recommends directly using translate.py, preprocess, and search.

I would have suggested "check python version in translate.py," but maybe that's 
too much trouble.  It seems ok to me that it would not catch 2.4, since that 
would already have been caught by build_all and also python parsing failure is 
such a gross error that it gives a good warning to the user.

Proposal:  check in build_all, and figure that's enough.  It seems like a good 
tradeoff between benefit to the user, and level of effort to you.

> I was hoping that it would be possible, inside the running python, to check the
> version number and if it was not > 2.6, raise an error.
> I hadn't thought about the question of whether the 
> entire script would be considered ill-formed.

I checked with Python 2.4, and get a syntax error before any code is executed,
unfortunately. So this would only work for 2.5.

Which of the following three options:

1) Test the Python version in "build_all", print a warning if version number
doesn't look good.

2) Test the Python version in "plan", print a warning if version number doesn't
look good.

3) Test the Python version in "plan", abort with an error if version number
doesn't look good.

do you like best? (Or is none of them good?) I would prefer 2), but in cases
like yours the warning might be somewhat nonobvious since there's a mass of text
below it.

The error is as follows:

Traceback (most recent call last):
  File "/usr/local/fast-downward/src//translate/translate.py", line 578, in 
<module>
    sas_task = pddl_to_sas(task)
  File "/usr/local/fast-downward/src//translate/translate.py", line 457, in 
pddl_to_sas
    partial_encoding=USE_PARTIAL_ENCODING)
  File "/usr/local/fast-downward/src/translate/fact_groups.py", line 107, in 
compute_groups
    groups = invariant_finder.get_groups(task, reachable_action_params)
  File "/usr/local/fast-downward/src/translate/invariant_finder.py", line 134, 
in get_groups
    invariants = list(find_invariants(task, reachable_action_params))
  File "/usr/lib/python2.5/contextlib.py", line 33, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/local/fast-downward/src/translate/timers.py", line 32, in timing
    yield
  File "/usr/local/fast-downward/src/translate/invariant_finder.py", line 134, 
in get_groups
    invariants = list(find_invariants(task, reachable_action_params))
  File "/usr/local/fast-downward/src/translate/invariant_finder.py", line 95, in 
find_invariants
    balance_checker = BalanceChecker(task, reachable_action_params)
  File "/usr/local/fast-downward/src/translate/invariant_finder.py", line 18, in 
__init__
    action = self.add_inequality_preconds(act, reachable_action_params)
  File "/usr/local/fast-downward/src/translate/invariant_finder.py", line 49, in 
add_inequality_preconds
    combs = itertools.combinations(range(len(action.parameters)), 2)
AttributeError: 'module' object has no attribute 'combinations'

The problem is that itertools introduced the 'combinations' function in the 2.6 
release.

I finally figured this out using python -V.  I was hoping that it would be 
possible, inside the running python, to check the version number and if it was 
not > 2.6, raise an error.  I hadn't thought about the question of whether the 
entire script would be considered ill-formed.  Perhaps such a check could be 
done inside build_all?  One could check the output of /usr/bin/env python -V and 
issue a warning if python is not sufficiently up-to-date?  It would just be a 
warning, because a sophisticated user would be able to force use of a better 
python if the one pointed to by /usr/bin/env (at this particular point in time) 
was not good.  But it might save some trouble.

Just thoughts.

What is the error message? Can you send a log snippet? How did you run the planner?

Having the translator give a suitable error message is one thing. Having the
overall planner present this error message properly is another.

There are a few issues here that an ideal solution should address. One is that
there is unfortunately no way to write the shebang line that works on all
systems that are in theory ready to run the planner. For example, some systems
have a suitable version of Python installed, but not under the "python" alias.
"Properly packaged" programs handle this by using an installation step that
updates the shebang line in an appropriate way, but I'd rather avoid this
complexity.

Another is that for certain kinds of Python version mismatches, the code fails
to even by syntactically correct, in which case there's no way to get at the
version number before the translator errors out. In such a case, the version
check would need to be done externally in a script, but if we unconditionally
run that, we'd incur additional Python startup overhead that we should avoid.
(It doesn't matter much for the usual IPC timings, but only this week I got an
email from a user who is adversely affected by a 200ms constant overhead of
running the planner.)

I don't know what the best solution is and am open for suggestions. I guess one
thing we can do is have the "plan" convenience scripts do more extensive
diagnosis and error reporting and recommend that users who'd like to avoid such
overhead should use the three planner components directly.

I was trying to run a bunch of experiments on an Ubuntu server in our lab, and
got VERY odd error messages.

After digging in a bit, I believe I have identified the problem:  that server is
still running python 2.5, but 2.6 is required to get the right version of the
itertools library.

I am not a python programmer, but I suspect there's probably some way to fix
translate.py so that if it doesn't have python 2.6 it will raise an error, and
if it's easy to do, that might be a kindness...