Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 11:02
    has2k1 commented #19040
  • 10:11
    clawfire commented #19000
  • 08:41
    dopplershift commented #19040
  • 08:09
    dopplershift commented #19043
  • 01:32
    wanganhong commented #19027
  • 01:31
    wanganhong commented #19027
  • 01:25
    wanganhong edited #19027
  • 01:25
    rfernand2 commented #19039
  • 01:14
    anntzer commented #19039
  • 01:13
    anntzer synchronize #19046
  • 00:53
    rfernand2 commented #19039
  • 00:52
    rfernand2 commented #19039
  • 00:50
    rfernand2 commented #19039
  • Nov 29 21:05
    anntzer labeled #19046
  • Nov 29 21:05
    anntzer opened #19046
  • Nov 29 21:05
    anntzer milestoned #19046
  • Nov 29 18:56
    story645 commented #19016
  • Nov 29 15:42
    anntzer labeled #19044
  • Nov 29 15:42
    anntzer labeled #19045
  • Nov 29 15:42
    anntzer labeled #19045
Antony Lee
@anntzer
"only alive via a refcycle and this reference"
I guess the cleaner solution is indeed to have close() actually mean destroy() (the C-level object)
and let the python side catch up whenever gc runs
Thomas A Caswell
@tacaswell
It is not clear to me that that is actually better
Antony Lee
@anntzer
at least that's deterministic?
Thomas A Caswell
@tacaswell
there are some things we def want to work after closing (like save!)
Antony Lee
@anntzer
that's fine, we don't need a live qtcanvas for that
Thomas A Caswell
@tacaswell
so if we do destroy we would have to make sure that enough of the python side works or swap out the canvas (which seems funny to do)
Antony Lee
@anntzer
we could always switch to backend_agg...
(or whatever is relevant)
Thomas A Caswell
@tacaswell
also, I am 100% sure we have users abusing this
Antony Lee
@anntzer
ok, but that's actually warnable
set a flag on close, and warn if people try to ressucitate stuff
Thomas A Caswell
@tacaswell
That will hopefully bring some people out of the woodwork to comment on why this is happening :-p
Antony Lee
@anntzer
actually I don't even think saving is going to be a problem, at worse we'll have to sprinkle a few sip.isdeleted here and there, but the actual rendering is done by something fully managed by ourselves
fwiw tk and gtk3 both call destroy on the widgets on manager destruction
indeed a quick try suggests only qt supports ressucitation currently (and per the above that's basically an implementation choice)
Jody Klymak
@jklymak

@tacaswell @anntzer: So we seem to have three alternatives:

import matplotlib as mpl
fig, axs = mpl.subplots()

or

import matplotlib.figure as mfigure
fig = mfigure.figure()
axs = fig.subplots()

or

import matplotlib.figwrapper as mfigwrap
fig, axs = mfigwrap.subplots()
Number 2 seems strained. Number 3 is going to be hard to convince most folks that its better than matplotlib.pyplot
Thomas A Caswell
@tacaswell
and I do not think that number 1 is a valid option due to the implicit configuration and global state issues
Jody Klymak
@jklymak
OK, and sorry if I'm being dumb, but I don't understand why thats a problem? What wires can get crossed?
I'm definitely not arguing with you - I just am ignorant
Thomas A Caswell
@tacaswell
Jody Klymak
@jklymak
OK, I find that very confusing, because the only way I know to switch the backend is matplotlib.use
Thomas A Caswell
@tacaswell
Matplotlib has two (ish) faces, one is very application like (pyplot which "just works" guesses the right GUI etc) and the library side (which you have be more explicit with)
Antony Lee
@anntzer
it's not obvious to me we absolutely do not want to move that to the toplevel; I guess I sort of see your point but heh
Thomas A Caswell
@tacaswell
if you have not imported pyplot yet mpl.use only sets a value in rcparams
and we do some sys.modules sniffing to sort out if you have already imported pyplot and we should try to be more helpful
Jody Klymak
@jklymak
OK, but none of that happens until a call to *.figure()?
Thomas A Caswell
@tacaswell
no, it is called on import of pyplot
but it does not lock its self until you make the first figure
Jody Klymak
@jklymak
OK, so you are saying importing pyplot does a bunch more than importing matplotlib, and that that extra state if imported by matplotlib may cause problems for folks who just want to use matplotlib in an embedded GUI
Thomas A Caswell
@tacaswell
yes
if anything we probably want to import fewer things in the __init__.py not more
There is another option which is
from matplotlib.backends.backend_qt5agg import figure, subplots
fig, ax = subplots()
Jody Klymak
@jklymak
ha, well thats definitely explicit
Thomas A Caswell
@tacaswell
which we almost have already
Jody Klymak
@jklymak
While figwrap is definitely a terrible name, a module like that would nicely separate the gcf scaffolding from the pyplot implicit axes-state, which are different things. We can give people a guiapp without it having all the implicit features of pyplot.
import matplotlib.figgui as mfig

fig, axs = mfig.subplots()
Isn't too bad and gives us the separation we want. We could even do mfig.use('backendname')
Thomas A Caswell
@tacaswell
Currently we also rely on the global registry for IPython to identify stale figures and ask for them to be re-drawn exactly once right before we return control to the user
we could always do the non-IPython method and just always call draw_idle when the figure gets marked as stale
Jody Klymak
@jklymak
I think my (fuzzy) conception wrapfig or figgui would be exactly what we currently have, and would even be interoperable with pyplot. It would just be a more restrictive version of pyplot that would protect the user from all the other things we don't like about pyplot, but keep all the same figure management.
Thomas A Caswell
@tacaswell
the easiest way to get that would be to put figure and subplots in a simple namespace and then have people do
from matplotlib.pyplot import restricted as plt
Jody Klymak
@jklymak
Sure... But that is harder to explain to people than: 1) here is the module you need to make a GUI figure, or figure you will save somehow 2) here is a different module that tracks what axes you are on and draws to that.
My point is that I think they are separate functionalities that we have mushed into one thing called pyplot.
Thomas A Caswell
@tacaswell
actually, I think the super explicit version works today...I have had a fact incorrect in my head, for approximately forever ...
Thomas A Caswell
@tacaswell
on one of our channels there was a report about set_window_title not working right with notebook
the workaround is to do fig.set_label and I have a still hacky, but better fix coming