[C++-sig] Extending/Embedding FAQ: How do I tell "incomplete input" from "invalid input"?

[Dietrich Bollmann]

Hi Andreas,

On Tue, 2008-04-22 at 22:25 -0400, Andreas Klöckner wrote:
> On Dienstag 22 April 2008, Dietrich Bollmann wrote:
> > Hi,
> >
> > some time ago I programmed an interactive python interpreter shell
> > using paragraph 16 of the Extending/Embedding FAQ
> 
> Knee-Jerk reaction: Why don't you just use InteractiveConsole from the std 
> library?
> 
> http://docs.python.org/lib/module-code.html

The reason was that the shell is split into a server part and a client
part: The code is executed in the server but comes from the client which
implements the shell.

The other reason was, that I found the FAQ and that I preferred do do
everything in c if I am already developing the client and server in c
rather than wrapping python into c code. 

But I found another solution thanks to you answer :)

The function `compile_command()':

  This function is useful for programs that want to emulate Python's
  interpreter main loop (a.k.a. the read-eval-print loop). The tricky
  part is to determine when the user has entered an incomplete command
  that can be completed by entering more text (as opposed to a complete
  command or a syntax error). This function almost always makes the same
  decision as the real interpreter main loop.

  (from http://docs.python.org/lib/module-code.html )

wrote a c wrapper around it and substituted it for `Py_CompileString()'.

As `compile_command()' contrary to `Py_CompileString()' understands if a
command is just incomplete or erroneous I got my code working again :)

So you saved my day, thank you very much :)

`compile_command()' uses a kind of strange strategy to decide if the
code is complete or not:

  Approach:

  First, check if the source consists entirely of blank lines and
  comments; if so, replace it with 'pass', because the built-in
  parser doesn't always do the right thing for these.

  Compile three times: as is, with \n, and with \n\n appended.  If it
  compiles as is, it's complete.  If it compiles with one \n appended,
  we expect more.  If it doesn't compile either way, we compare the
  error we get when compiling with \n or \n\n appended.  If the errors
  are the same, the code is broken.  But if the errors are different, we
  expect more.  Not intuitive; not even guaranteed to hold in future
  releases; but this matches the compiler's behavior from Python 1.4
  through 2.2, at least.

  (from the source file header)

but for the moment it works and I hope that enough people depend on the
code so that I do not have to fix my code for every new Python
release...

Still, the Python Extending/Embedding FAQ should be updated as other
people might stumble over the same problem.

Does anybody know who is responsible for the FAQ?

Thanks for putting me into a good mood again :)

Dietrich

> Andreas