Re: [matplotlib-devel] hashing of FontProperties
Jae-Joon Lee wrote: > The following code show how the FontProperties is currently hashed. > > def __hash__(self): > l = self.__dict__.items() > l.sort() > return hash(repr(l)) > > > The hash does not account user's rcParams setting. And due to the font > caching, findfont(FontProperties()) returns the same font even if user > changes the rcParams["font.family"] and other parameters. > > So, I propose to change it to something like below. > > def __hash__(self): > l = [(k, getattr(self, "get" + k)()) for k in self.__dict__] > return hash(repr(l)) > You'll need to maintain the call to sort in there, since dictionaries don't make any guarantee about ordering. But otherwise, that seems like a reasonable solution to the problem. There was a bug report about this on the list recently. > The other change I want to make is the behavior of the findfont(None). > As of now, it returns "fontManager.defaultFont" which is set when > fontManager is initialized. Therefore, it returns same font even if > user change the rcParams. I prefer to have "findfont(None) == > findfont(FontProperties())". > That should be fine. > Unless others object, I'll commit the changes to the trunk. > Sure. Just be careful not to change the pickled cache file format if possible (it doesn't seem like what you propose will do that) -- but that always causes upgrade headaches when that cache format changes. Mike -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] File format for plots
On Sun, Mar 1, 2009 at 8:17 AM, sam tygier wrote: > Eric Firing wrote: > > Sandro Tosi wrote: > >> Hi Sam, > >> > >> On Wed, Feb 25, 2009 at 09:35, sam tygier > wrote: > >>> I think this topic has come up before, but i don't think anything has > >>> resulted from it. > >>> > > Correct, because the capability would require a *lot* of work to > > implement, > > Would i be right in assuming that it would take roughly the same amount of > effort as writing a new backend? ie for each motplotlib action it would need > a function to store that action and a function to call that action again. > > > and most of us don't see a compelling need; we believe that a > > better practice is to structure one's work so that plotting is separated > > from data (result) generation in any cases where the latter is highly > > time-consuming. > > It might not be essential, but it would offer an additional work flow, that > a few people seem to like. > > I think it would be especially useful when it comes to putting plots into > papers. I often find that i want to tweak something like the font size or > labels. having a modifiable plot format seems the easiest way to achieve > that. maybe the could even be some integration into latex so that if you > were to resize your plot in your paper, it would be re-rendered with the > fonts adjusted. Other than the automatic regeneration from latex, what you want sounds like what we already have: small python scripts. In general, I'm completely amazed by how many people want to develop a new markup/script language to wrap what is already a simple and expressive language, both for plots and (at least around here) analyses. If there are some spots that require too many lines of code to accomplish something really simple, then maybe we need to API additions. But in general, I think we have a format for specifying how to make a plot: python. Now, if we're taking the output from some monstrous application or set of scripts, it might be nice to get the commands that made the plot, like MayaVi 2 and its ability to record. However, at the end of the day what MayaVi creates is a python script, and I think that's more useful than any general markup since I can look at that file and figure out what's going on without learning anything new. Now, a matplotlib backend that writes out python code could be useful and cool, though it would only matter for the large applications/scripts. In fact, it's at the application level that such functionality would probably belong. My 0.02 anyways. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from: Norman Oklahoma United States. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] File format for plots
On Mon, Mar 02, 2009 at 01:49:38PM -0600, Ryan May wrote: >Other than the automatic regeneration from latex, what you want sounds >like what we already have: small python scripts. >In general, I'm completely amazed by how many people want to develop a new >markup/script language to wrap what is already a simple and expressive >language, both for plots and (at least around here) analyses.� If there >are some spots that require too many lines of code to accomplish something >really simple, then maybe we need to API additions. But in general, I >think we have a format for specifying how to make a plot: python.� Although I agree with you that reinventing an extra scripting layer is often a bad solution to a problem which should simply be solved by having a good scripting API in Python, I believe there is here a fundamental misconception. Python is an imperative, Turing-complete. This is a very good thing for a scripting language. For making a description of a static object as a plot, this is not a good thing. For instance, if I want to make a plot, save it, and later blow up all the fonts, I really don't want to be using an imperative, Turing-complete language for the persistence model, as static analysis of this persisted object is going to be next to impossible. Same thing if I want to change colormaps, or just about anything in my persisted object, for the same reason. A good rule for most software design is that the state of the application, or of the object of interest, in our case the plot, should be fully represented by a fully-static set of values, that I like to call the model. Although this sounds like a tautology, this design rule is more often broken than followed. For instance the status of an application may be entirely dependent on its past, or the important state variables may be hidden in places where you can't get hold of them (eg the status of a GUI widget, or inside a generator). Having a very clean separation between your (fully-static) model, and the logics around is a very important part of good application design, and I believe I know this because I have so often made an error and violated this rule :). If you have this static model, rather than an imperative language, then you can have persistence. By the way, Mayavi2 achieves its code generation by introspection on the model. The generated lines of code are just a way of expressing the changes. Sorry for being fussy, I am just trying to pass on what I believe I am learning painfully :). Ga�l -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Updating MPlot3D to a more recent matplotlib.
Hi, I saw that 3D plotting was dropped from matplotlib since the last time I used it. Unfortunately, it is pretty necessary for some of the work I am doing. Thus, I have started the process of refactoring the code to work with recent versions of matplotlib. Right now, it is still in very early stages and is quite flaky but I do have some functionality. In particular, I am able to do a regular 3d plot, a wireframe plot and a scatter plot. If this interests anyone I am making the code available via git. Instructions are available on my website at: http://jonathantaylor.ca/projects.shtml Feel free to send any patches my way. Best, Jon. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
