Terry, Ian, thank you for your answers. On Sat, Apr 9, 2011 at 1:30 AM, Terry Reedy <tjre...@udel.edu> wrote: [...] > According to the above, that should be stream-of-parsed-expressions.
Good catch. > The question which you do not answer below is what, if anything, you want to > do with error? If nothing, just pass. You are now, in effect, treating them > the same as normal results (at least sending them down the same path), but > that does not seem satisfactory to you. If you want them treated separately, > then send them down a different path. Append the error report to a list or > queue or send to a consumer generator (consumer.send). The code above implements an interactive session (a REPL). Therefore, what I'd like to get is an error information printed out at the output as soon as it becomes available. Piping the errors together with data works fine (it does what I need) but it feels a bit clunky [1]. After all exceptions were specifically invented to simplify error handling (delivering errors to the caller) and here they seem to chose a "wrong" caller. Ignoring the errors or collecting them out of band are both fine ideas but they don't suit the interactive mode of operation. [1] It's actually not _that_ bad. Exceptions still are very useful inside of each of these procedures. Errors only have to be handled manually in that main data path with generators. Thanks, -r -- http://mail.python.org/mailman/listinfo/python-list
