>> (6) Mark Hammond suggests that it might be easier to >> replace the interactive portions of python based on the >> "code" module. matplotlib suggests using ipython >> instead of standard python for similar reasons.
>> If that is really the simplest answer (and telling users >> which IDE to use is acceptable), then ... I think Michiel >> has a point. Fredrik Lundh wrote: > really? Python comes with a module that makes it trivial to get > a fully working interpreter console ... Using an event loop (or an external GUI) should not require forking the entire interactive mode, no matter how trivial that fork is. The subtle differences between interactive mode and IDLE already cause occasional problems; the same would be true of code.interact() if it were more widely used. Part of Michiel's pain is that users want to make their own decisions on whether to use IDLE or emacs or vt100, and they want to mix and match toolkits. They already run into unexpected freezes because of the event loop conflicts. If every extension writer also relied on their own subclasses of the interactive mode, users would be in for far more unpleasant surprises. The right answer might be to run each event loop in a separate thread. The answer might be to have a python event loop that re-dispatches single events to the other frameworks. The answer might be a way to chain PyOS_InputHook functions like atexit does for shutdown functions. The answer might be something else entirely. But I'm pretty sure that the right answer does not involve adding an additional layer of potential incompatibility. -jJ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
