What's the status of the py3k branch?

Hi,

···

On Sat, Feb 26, 2011 at 4:30 AM, Michiel de Hoon <mjldehoon@...42...> wrote:

In any case it appears that with the exception of Tkinter, it may take a
long time before interactive mpl backends can be used with py3k.

The MacOSX backend has already been ported to Py3k (at least the C part of it, which is the largest and most difficult part of it), though I won't be able to test it until the rest of matplotlib has been ported.

The damn-ing part about the backends is that many users use only one of
the GUI backends, and if that one is broken for them, they believe that
matplotlib is completely broken. (Evidence: the user who complained
that matplotlib was not designed correctly when it turned out that the
macosx backend didn't support (non-?)interactive mode).

Sometimes I wonder if it is better to retire the MacOSX backend. When it was first introduced, it was much faster (depending on what you wanted to draw) because of how its event loop is organized. By now the other backends use the same event loop strategy, and as far as I know there is no significant difference in speed compared to e.g. the TkAgg backend. The remaining advantage of the MacOSX backend is that it does not rely on other toolkits, and therefore it is easier to compile and use if something changes (e.g., when a new version of OS X comes out, or when compiling for 64-bits, or when Py3K comes out). Still, it needs some maintenance work, and it is hard to keep up.
Opinions, anybody?

Seconding Jeff - I use the MacOSX backend too - was very grateful not
to have to install the other toolkits or suffer ugliness. So, I'm
also grateful...

Best,

Matthew

I agree that this should be done, but I just haven't found the time to look at it (recently I have been looking at getting animations to work with the MacOSX backend). Probably it is not all that hard, and I would welcome contributions from other developers who use the MacOSX backend to get the non-interactive mode behavior consistent with the other backends.

On a related note, something I found confusing for new matplotlib users is that after first installing it, matplotlib is non-interactive by default. After installing matplotlib, I think users should be able to try it out and make some simple plots that appear on the screen without having to find out about interactive behavior and edit matplotlibrc. Especially people that are new to programming or to Python may be disappointed if their first plotting attempts don't seem to produce a figure.

--Michiel.

···

--- On Sat, 2/26/11, Eric Firing <efiring@...229...> wrote:

What about the non-interactive mode behavior--is it hard to
make the MaxOSX backend behave like the others in that
respect?

What about the non-interactive mode behavior--is it hard to
make the MaxOSX backend behave like the others in that
respect?

I agree that this should be done, but I just haven't found the time to look at it (recently I have been looking at getting animations to work with the MacOSX backend). Probably it is not all that hard, and I would welcome contributions from other developers who use the MacOSX backend to get the non-interactive mode behavior consistent with the other backends.

On a related note, something I found confusing for new matplotlib users is that after first installing it, matplotlib is non-interactive by default. After installing matplotlib, I think users should be able to try it out and make some simple plots that appear on the screen without having to find out about interactive behavior and edit matplotlibrc. Especially people that are new to programming or to Python may be disappointed if their first plotting attempts don't seem to produce a figure.

That's a good point. Until fairly recently, interactive behavior worked across backends only via ipython magic, so I think the non-interactive default had a solid historical rationale. Now, however, we could probably make interactive mode the startup default for interactive backends without causing any problems. I agree that this would be more intuitive and more familiar to people coming from matlab.

Eric

···

On 02/26/2011 04:25 PM, Michiel de Hoon wrote:

--- On Sat, 2/26/11, Eric Firing<efiring@...229...> wrote:

--Michiel.

Probably right -- this was a design decision made early on when I did
not see a good way around the problem that the idle drawing across
backends now solves. There will probably be some unintended
consequences of changing the default, but as long as we document it
prominently and provide a way for people to change the behavior to the
old wan in their rc, it is probably a good idea to make this change.

···

On Sun, Feb 27, 2011 at 1:06 AM, Eric Firing <efiring@...229...> wrote:

That's a good point. Until fairly recently, interactive behavior worked
across backends only via ipython magic, so I think the non-interactive
default had a solid historical rationale. Now, however, we could
probably make interactive mode the startup default for interactive
backends without causing any problems. I agree that this would be more
intuitive and more familiar to people coming from matlab.