Mailman 3 September 2015 - Matplotlib-devel

MPL2 Logo
by OceanWolf Oct. 13, 2015

Oct. 13, 2015

Looking at the current logo, I wondered whether we would want to change this as part of the style changes when we release 2.0... as well as marketing our new style, the current logo uses jet to make the graph... Playing around with the examples/api/logo2.py I found changing line 68 to: bar.set_facecolor(cm.viridis(r/8.)) gave pleasing results with the largest wedge getting coloured green (see attached for uncropped version).

7 9

[Error 17]No usable Temporary file name found.
by programmer86 Oct. 9, 2015

Oct. 9, 2015

Hi, I developed a tool in Python 2.7.8 and packaged it using "py2exe". When I run the tool I get the following error Traceback (most recent call last): File "application_gui.py", line 2, in <module> File "modules\Application.pyc", line 13, in <module> File "modules\Base.pyc", line 15, in <module> File "matplotlib\__init__.pyc", line 764, in <module> File "matplotlib\__init__.pyc", line 682, in rc_params File "matplotlib\__init__.pyc", line 595, in matplotlib_fname File "matplotlib\__init__.pyc", line 248, in wrapper File "matplotlib\__init__.pyc", line 470, in _get_configdir File "matplotlib\__init__.pyc", line 176, in _is_writable_dir File "tempfile.pyc", line 462, in NamedTemporaryFile File "tempfile.pyc", line 251, in _mkstemp_inner IOError: [Errno 17] No usable temporary file name found I am using matplotlib 1.4.3. Thanks, Srinath. -- View this message in context: http://matplotlib.1069221.n5.nabble.com/Error-17-No-usable-Temporary-file-n… Sent from the matplotlib - devel mailing list archive at Nabble.com.

2 1

supported python versions
by Thomas Caswell Oct. 8, 2015

Oct. 8, 2015

Hey all, I would like to propose the following for which version of python mpl officially supports: - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5 - for v2.0 forward we support (2.7, 3.4, 3.5) and allow for new, python3 only, features to be developed for mpl2.1 onward, so long as they do not break any existing functionality in py2.7. We already support all of those versions on master, there is no good reason to drop 2.6 support right before the RC. For 2.0 we should drop 2.6 so that we do not have to maintain a mpl2.0.x py2.6 compatible bug-fix branch. Regarding dropping 2.6 as a supported version I suggest you read/watch the following from Nick Coghlan: http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html http://www.pyvideo.org/video/3764/contributors-colleagues-clients-customers… We are resource limited and those resources would be better spent improving the library and supporting modern version of python. At some point it is unreasonable for people running very old installations of python to expect the the newest versions of down-stream tools to work. If this is important to someone, please step up to mange maintaining a 1.5.x bug-fix branch which will maintain 2.6 compatibility. Dropping 2.6 will also free us to being using OrderedDict and several other language features added in 2.7. Regarding dropping 3.3, every survey has shown that among the users who have adopted py3, a vast majority are using the newest version so supporting and testing against the older versions of 3 is not worth the effort. In all cases, versions of mpl that currently work on legacy versions of python will continue to work. Thanks to Eric, Mike, and Phil who have this a read over. Tom

10 29

Gauging interest in a AsynchronousAnimation class
by toemoss garcia Oct. 5, 2015

Oct. 5, 2015

Hi, Out of my own needs I developed an animation class that is very similar to FuncAnimation but is drawn asynchronously (not that this couldn't be done with FuncAnimation, this is just a more direct path). Instead of trying to explain the differences off the bat I'll give a base example usage fig, ax = plt.subplots() x = np.arange(0, 2*np.pi, 0.01) line, = ax.plot(x, np.sin(x)) ani = AsyncAnimation(fig,interval=50) fig.show() # starts the first 'draw' without entering the mpl mainloop i = 0 while ani.update(): #update() flushes the animation's queue i += 1 y = np.sin(x+i/10.0) ani.append_artist(line,(x,y)) This is the simplest example, where one frame is queued at a time and `update()` blocks execution until that frame has been rendered (so this is effectively the same as a FuncAnimation). Aesthetically, the difference is that the animation code lives inside a loop instead of a function call. This removes the need to have the animation code pass variables back to the user or doing any global imports of variables which IMHO makes the application code cleaner and more self-contained. Personally, I find this a simpler and more intuitive way to write interactive animation applications. (Alternatively, writing application code inside of a class that uses FuncAnimation gives you similar benefits of cleaner code). The other more significant difference is that having rendering being done asynchronously basically decouples the animation code from the application code, which 1. Makes it trivial to execute the graphics rendering as a separate process 2. Gives the user more flexibility in their application code (you could imagine an application "queueing up" multiple frames at a time, allowing them to render in their own time). Anyway, here is the code as it stands now (most important are the `append_artist` and `update` functions; the rest of the code is very similar to the FuncAnimation class): class AsyncAnimation(Animation): """ Makes an animation by reading from a user filled queue every *interval* milliseconds. User adds to the queue by calling *update_artists*. Note that data is _not_ copied before being put into the queue; if a reference is passed (such as a numpy ndarray) whatever data the reference is pointing to at draw time will be plotted. *init_func* is a function used to draw a clear frame. If not given, the results of drawing from the first item in the frames sequence will be used. This function will be called once before the first frame. *event_source* Default event source to trigger poll of the artist queue. By default this is a timer with an *interval* millisecond timeout. """ def __init__(self,fig,init_func=None,event_source=None,interval=10,blit=True): self._data = deque() self._lag = 0 self._queued = False self._fig = fig self._interval = interval self._init_func = init_func if event_source is None: event_source = fig.canvas.new_timer(interval=self._interval) Animation.__init__(self,fig,event_source=event_source,blit=blit) def new_frame_seq(self): return itertools.count() def _init_draw(self): if self._init_func is not None: self._drawn_artists = self._init_func() for a in self._drawn_artists: a.set_animated(self._blit) def _draw_next_frame(self, *args): # carry on if there's nothing to draw right now if self._data: Animation._draw_next_frame(self,*args) def _draw_frame(self,framedata): artdata = self._data.popleft() artists = [] for (a,d) in artdata: artists.append(a) if d is not None: a.set_data(d) a.set_animated(self._blit) self._drawn_artists = artists def append_artist(self,artist,data=None): self._queue_artists((artist,data),) def extend_artists(self,artists): self._queue_artists(*artists) def _queue_artists(self,*artists): if len(self._data) and self._queued: self._data[-1] += artists return self._queued = True if len(self._data) > self._lag: warnings.warn("Artists queue is behind by %d" % len(self._data)) self._lag = len(self._data) self._data.append(artists) def update(self,block=True): self._queued = False self._fig.canvas.flush_events() if block: while len(self._data) and self.event_source is not None: self._fig.canvas.flush_events() return self.event_source is not None So, I've developed this code enough that it fills my needs, but it needs some work to add in all the expected matplotlib functionality. Is something that would be useful to people?

2 1

Requesting code review
by Jouni K. Seppänen Sept. 26, 2015

Sept. 26, 2015

I'd like a code review of my pull request: https://github.com/matplotlib/matplotlib/pull/5106 The request is meant to fix a crashing bug: https://github.com/matplotlib/matplotlib/issues/5105 I'll try to explain what changes I'm making in the code. Since I'm not the original author of the code, all claims about the intent of the code are just my interpretation. The major change is to numpy_cpp.h, the set method of the array_view class. This method is supposed to set the fields of the array_view object to match the array passed in. The method can return 0 for failure, or 1 for success. In case of failure, it should free all memory that was allocated. If it replaces the dynamically-allocated member m_arr, the former value needs to have its reference count decremented. The array_view class is templated on the number of dimensions ND, so e.g. a two-dimensional view can only have a two-dimensional buffer. Before this patch, the set method treats zero-dimensional arrays and arrays whose first dimension is zero as compatible with any number of dimensions, but it leaves the m_shape member NULL, which causes the crash. I think PyArray_DIMS(m_arr) returns NULL for zero-dimensional arrays. The zeros array that is used instead is just a constant array of zeros. It is not enough to just return failure in that case, since there are many cases in the code where an empty array is assigned to a view. Instead, I change the logic as follows: 1. if ND is zero and the number of dimensions in the assigned buffer is zero, that counts as a success 2. if the first dimension of the assigned buffer is zero, that counts as a success too, so you can assign an empty buffer that doesn't have the correct number of dimensions 3. otherwise, if the number of dimensions fails to match, that's an error. A smaller change in _path_wrapper.cpp adds a try-catch form around code that uses array_view so that we get more useful error messages at Python level. The code is almost the same as a block above it, and many people consider using exceptions for control flow a bad thing. I wanted to make a minimal change to the code, and this preserves the semantics while improving the error message. -- Jouni K. Seppänen http://www.iki.fi/jks

1 0

Fwd: [NumFOCUS Projects] grant opportunity
by Thomas Caswell Sept. 24, 2015

Sept. 24, 2015

If anyone has some downtime and would like to be paid to hack on open source. Submissions are due Sept 30 Tom ---------- Forwarded message --------- From: Gina Helfrich <gina(a)numfocus.org> Date: Fri, Sep 18, 2015 at 12:10 PM Subject: [NumFOCUS Projects] grant opportunity To: <projects(a)numfocus.org> Hi all, Wanted to bring this opportunity to your attention: Stripe is looking to host three to four developers at their San Francisco office for three months to work full-time on an open-source project. The grant is no-strings-attached: $7,500 per month in addition to desk space at our office and meals during the week. "We want to provide everything needed to focus and have a substantial impact on an open-source project." More info: https://stripe.com/blog/open-source-retreat-2016 The program will run from January 15th until April 15th, 2016 at Stripe HQ in the Mission District of San Francisco. Best, Gina -- *Gina Helfrich, Ph.D.* *Communications Director* NumFOCUS <http://www.numfocus.org/> | Open Code, Better Science gina(a)numfocus.org | 512-222-5449 -- You received this message because you are subscribed to the Google Groups "Fiscally Sponsored Project Representatives" group. To unsubscribe from this group and stop receiving emails from it, send an email to projects+unsubscribe(a)numfocus.org. To post to this group, send email to projects(a)numfocus.org. Visit this group at http://groups.google.com/a/numfocus.org/group/projects/. To view this discussion on the web visit https://groups.google.com/a/numfocus.org/d/msgid/projects/CAFhTXRPxOsUubAHE… <https://groups.google.com/a/numfocus.org/d/msgid/projects/CAFhTXRPxOsUubAHE…> .

1 0

Update polar examples?
by OceanWolf Sept. 21, 2015

Sept. 21, 2015

During my investigation for MEP29 I have noticed in the docs (of figure.py) that: > (For backward compatibility, ``polar=True`` may also be provided, which is equivalent to ``projection='polar'``). But all the polar examples use ``polar=True``, so perhaps we should change the examples to match our current preference (aka ``projection='polar'``)? I say perhaps, because I do feel torn about this, because I *may* want to change this again with MEP29 assuming it gets accepted once I have finished writing it. I guess I err on updating the examples now because it doesn't hurt, and updating them again later if/when we change stuff. Shall I just make a PR of this now? Can it still make 1.5? Would we have to backport it, or will it go straight it? Best, OceanWolf

2 1

nbagg and exceptions raised by callbacks
by Nathan Goldbaum Sept. 21, 2015

Sept. 21, 2015

Hi all, I'm having a bit of an issue trying to debug a plot callback using the nbagg backend. The following notebook illustrates the issue: https://gist.github.com/anonymous/e6cb1acd8bfbfda35bf1 If you run that notebook (based on an example in the maptlotlib documentation; I'm using IPython 4.0 and Matplotlib 1.5rc), and try to zoom in on the right-hand panel the exception raised by the ax_update function is never propagated up to the level of the user. If I remove the call to "%matplotlib notebook" from the first cell and run the notebook, a GUI window provided by the MacOSX backend will pop up, and if I zoom into the right-hand plot there, an exception does get printed in the notebook. Is this a bug in the nbagg backend or is there some sort of runtime parameter I need to set to make sure exceptions raised while updating an nbagg plot get propogated back up to my runtime environment? Thanks for your help, Nathan Goldbaum

1 1

Figure size and DPI for interactive figures
by Thomas Robitaille Sept. 19, 2015

Sept. 19, 2015

Hi everyone, I've been working on trying to make the canvas in the PyQt5 backend have a higher resolution on HiDPI/retina displays: https://github.com/matplotlib/matplotlib/issues/4977 but as part of this, I've become very confused about what we want the *expected* behavior to be for the DPI setting when making interactive figures. Let's say that I start from a clean install of Matplotlib, so the default figure size is (8,6) and the default DPI is 80. If I make a figure with the MacOS X backend, the figure has the same physical size relative to other windows in the OS regardless of whether the display is a retina display or not. However, on retina displays, the canvas is nice and crisp, so in fact the *real* DPI is 160 not 80. In other words, the number of pixels in the canvas is *not* (8 * 80, 6 * 80) but double in each direction. If I now set the DPI to 160, the *figure* size doubles and the actual DPI stays the same. With PyQt4, while there is no support for HiDPI/retina displays, I see the same behavior of the figure size doubling if I double the DPI. In other words, figure size and DPI do not really mean what they should mean for interactive figures, and furthermore for the MacOS X backend on retina displays, the real DPI is double the one in the settings. So what this means is that (based on the MacOS X backend) the real figure size is figsize * dpi, and the real DPI is whatever the screen is. First, is this all expected behavior? And second, should I try and implement the same behavior for PyQt5, namely that on HiDPI displays, a figure with a figure.dpi of 80 will actually look crisp (so it will be internally doubled)? Thanks for any advice! Cheers, Tom

1 0

Suggestion: accept callables as non-xs values arguments
by Andy Buckley Sept. 18, 2015

Sept. 18, 2015

Hi, Not sure if this is the best place to post this, but I have an API suggestion: as well as iterables, mpl plotting functions could accept callable objects to generate y values, errors, etc.. Specifically, I'm thinking that the list of x values would always need to be specified as an iterable like now, but that the other arguments which currently require an iterable of the same length as the xs could alternatively accept callables that are mapped on to the xs list. The presence of __iter__ or __call__ attributes could be used to determine which approach to use. I searched a bit and couldn't find any previous mention of this idea, and there are callable arguments already used in matplotlib. Thoughts? I'd be happy to help with implementation if there is any interest. Best wishes, Andy

3 3