[IPython-dev] GUI support: conflicts between IPython 0.11 and Matplotlib/ETS

Gael Varoquaux gael.varoquaux@normalesup....
Fri Feb 12 04:17:22 CST 2010


On Fri, Feb 12, 2010 at 11:08:18AM +0100, Hans Meine wrote:
> > > Huh?  Honestly, why should applications modify their __main__ to check
> > > for *existing* global objects -

> > Because nobody should code thinking they own the main. It makes debugging
> > and reusing much harder.

> But I am thinking of mains like the following:

> if __name__ == "__main__":
> 	import sys

> 	app = QtGui.QApplication(sys.argv)

> 	mw = BeverageMainWindow()
> 	mw.resize(800, 600)
> 	mw.show()
> 	sys.exit(app.exec_())

> This is a prototypical __main__ which I'd like to be able to %run from
> IPython as well as from the commandline.  If I want to reuse code, I'll
> import the file and reuse BeverageMainWindow, but not the __main__
> code.

OK, but in the above code, you are saying that you want to own the
application object. What if you want to interact with other code that
does the same thing? There can only be one like this.

> > That's my point of view, and it comes from a long experience of trying to
> > help people run code, debug code, or simply get the job done using third
> > party code.

> Maybe then those people put too much code into __main__?

Most probably, but if you follow this logic, then you end up deciding
that nobody should ever create a new application object without checking
that one already exists, unless they want exactly that (eg for explicit
threading reasons).

What I am trying to say is that you have contradictory requirements: you
are asking for full ownership of the application, but you would also like
to play nice with other environments. This is going to fail, and not only
in IPython. I'd be interested: how does such code behave when run through
an execfile in a PyQt IDE, for instance eric4 or spyder?

Basically, whoever requires control and ownership of a global state will
be limited in its interaction with other programs, and I don't believe
there is a way around it.

Gaël


More information about the IPython-dev mailing list