Re: [matplotlib-devel] mlab and pylab
Just a bad example. I know there are functions that were originally defined in Matlab and then got rewritten in python, but I've never been clear on which modules they really live in. Ryan May wrote: > Tom Holroyd (NIH/NIMH) [E] wrote: >> Eric Firing wrote: >>> Similarly, after dealing with mlab, I would like to simplify pylab. >>> Right now, we have a horrible tangle of namespaces in pylab. Cleaning >>> this up will potentially break user code; if a numpy function formerly >>> could be referenced with three different names and we knock that down to >>> one, code using the other two will not work. My guess is that in >>> practice the amount of breakage will be *very* small and easy for users >>> to deal with. >> I for one will be happy to change my code; numerical stuff in numpy, >> plotting stuff in pylab (or pyplot?), though some things like linspace() may >> be hard to loose; that's really an mlab function and I can import mlab. It >> probably makes more sense. > > I'm not sure if linspace was just a bad example, but it does exist > within numpy itself. > > Ryan > -- I say to you: good and evil which would be everlasting- it does not exist! Of its own accord must it ever overcome itself anew. -- thus spoke Zarathustra - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mlab and pylab
Eric Firing wrote: > Similarly, after dealing with mlab, I would like to simplify pylab. > Right now, we have a horrible tangle of namespaces in pylab. Cleaning > this up will potentially break user code; if a numpy function formerly > could be referenced with three different names and we knock that down to > one, code using the other two will not work. My guess is that in > practice the amount of breakage will be *very* small and easy for users > to deal with. I for one will be happy to change my code; numerical stuff in numpy, plotting stuff in pylab (or pyplot?), though some things like linspace() may be hard to loose; that's really an mlab function and I can import mlab. It probably makes more sense. For the C library you say "man strcpy" or "man erf" and it tells you what include file to use to get the definition (function prototype). In python you only get the help after you've already imported. But it was and still is reasonable to have an import statement like an #include to define stuff you need. If I'm looking at somebody else's code and I see "linspace" or something, it would be nice to have a "man linspace" or so, that tells me which module I need to import. Is there a way to convert doc strings to man pages? Speaking as somebody who has bascially switched from "write it in C and use assembly for speed" to "write it in Python and use C for speed". -- I say to you: good and evil which would be everlasting- it does not exist! Of its own accord must it ever overcome itself anew. -- thus spoke Zarathustra - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Font installation stuff
Michael Droettboom wrote: [...] > All this raises a much larger question of whether we want to replace > font_manager.py with something like fontconfig. There don't appear to > be Python wrappers for it, but it would eliminate a number of issues > with font_manager.py : a) it would look up fonts in the same way as many > other apps in the OS (rather than from hard-coded folders), and b) seems > a little more correct in how it looks up fonts and substitutes for > missing fonts etc. For instance, if font_manager.py doesn't find an > exact match, it always returns Vera Sans, rather than returning > something with the same slant and weight as what you requested. There > would be no need to manually flush the matplotlib font cache, since > fontconfig would deal with all of that. > > [The Python wrappers are probably a non-issue on Unix-like systems, > since you can call out to the "fc-match" command for lookup.] > > This may be more effort than it's worth -- but I wanted to get opinions > from others on this list. I find the fontconfig web site inscrutable; I don't understand how the library would be used by mpl in practice. I get the impression that it needs to be installed and configured at a system level--is this correct? How would it work on OSX and Win? Eric > > Cheers, > Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Font installation stuff
I just finished writing code to support scalable mathtext with the Cairo backend. (The old version rendered the mathtext to bitmaps first). Mostly straightforward, but I ran into one small snag. It *seems* that pycairo requires that the fonts it uses are installed and accessible through fontconfig, i.e. you can not load a font by filename. Not a big deal, but there is also no way to tell if a particular font family matched exactly, and thus no way to warn a user that they need to install the Bakoma fonts. There are some ways out of this. It appears possible to load a font from a file for Cairo in C (though apparently different for each platform). I would hate to have to support another extension in matplotlib, but maybe the pycairo folks would be amenable to adding this. Probably worth dropping a note to the pycairo list either way. Or, we could find some way to install fonts automatically. That's fundamentally a packaging/distribution issue. All this raises a much larger question of whether we want to replace font_manager.py with something like fontconfig. There don't appear to be Python wrappers for it, but it would eliminate a number of issues with font_manager.py : a) it would look up fonts in the same way as many other apps in the OS (rather than from hard-coded folders), and b) seems a little more correct in how it looks up fonts and substitutes for missing fonts etc. For instance, if font_manager.py doesn't find an exact match, it always returns Vera Sans, rather than returning something with the same slant and weight as what you requested. There would be no need to manually flush the matplotlib font cache, since fontconfig would deal with all of that. [The Python wrappers are probably a non-issue on Unix-like systems, since you can call out to the "fc-match" command for lookup.] This may be more effort than it's worth -- but I wanted to get opinions from others on this list. Cheers, Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mlab and pylab
Ryan May wrote: >> I for one will be happy to change my code; numerical stuff in >> numpy, plotting stuff in pylab (or pyplot?), though some things >> like linspace() may be hard to loose; that's really an mlab >> function and I can import mlab. I'm a big namespace fan. I'd much rather see us all do something like: import pyplot import numpy as N import mlab etc. In this case, there should be little name overlap between these modules, and you could "import *" all of them if you really wanted. However, they are not all maintained by the same folks, so some overlap may occur, and that's a good reason for keeping them in separate namespaces. In any case, it needs to be decided what the point of the mlab module is. There was a discussion about this a few (quite a few!) years ago when there was just Numeric, and it came with an mlab module (at least I think it was called mlab). At that point, we decided that Matlab compatibility wasn't really the point -- the point was that there were a number of nifty utilities in Matlab that people missed, and that the stuff in mlab wasn't completely Matlab compatible anyway (numpy and Matlab are just plain different, after all). We more or less decided to what we really needed was a "Utilities" module that could hold some of those nifty useful functions (like linspace, etc), but not much was done at the time. Since then, numpy as gained quite a bit of those features anyway. So for this mlab module -- what is the goal? 1) A Matlab-like set of tools? In that case, it way want to default to matrices, rather than arrays, etc. If that's what's wanted, I'd make it a stand-alone module, that imports what it needs from numpy, but provides a complete API. 2) A bunch of extra utilities that numpy doesn't have, but are handy. In that case, I'd have it include only the extras, and one would need to import numpy and mlab both. It could also "import *" numpy , then add the extra stuff, but I'm too much of a namespace fan to advocate for that. What happens when numpy adds a name that clashes with an mlab name, for instance? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mlab and pylab
Tom Holroyd (NIH/NIMH) [E] wrote: > > Eric Firing wrote: >> Similarly, after dealing with mlab, I would like to simplify pylab. >> Right now, we have a horrible tangle of namespaces in pylab. Cleaning >> this up will potentially break user code; if a numpy function formerly >> could be referenced with three different names and we knock that down to >> one, code using the other two will not work. My guess is that in >> practice the amount of breakage will be *very* small and easy for users >> to deal with. > > I for one will be happy to change my code; numerical stuff in numpy, plotting > stuff in pylab (or pyplot?), though some things like linspace() may be hard > to loose; that's really an mlab function and I can import mlab. It probably > makes more sense. I'm not sure if linspace was just a bad example, but it does exist within numpy itself. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mlab and pylab
Tom Holroyd (NIH/NIMH) [E] wrote: [...] > > For the C library you say "man strcpy" or "man erf" and it tells you > what include file to use to get the definition (function prototype). In > python you only get the help after you've already imported. But it was > and still is reasonable to have an import statement like an #include to > define stuff you need. If I'm looking at somebody else's code and I see > "linspace" or something, it would be nice to have a "man linspace" or > so, that tells me which module I need to import. Is there a way to > convert doc strings to man pages? I don't know of any such tool, but it could be done. I don't think it would solve the problem you refer to, though, which I understand as wanting to know where a given function actually comes from. One of the problems with creating a huge number of man pages for this is that function names may be duplicated; linspace, for example, could be coming from numpy or from mlab (until we get everything cleaned up...). So, I think you are stuck with two approaches: actually tracing imports back through the code, or running ipython, importing a module, and then using the ? facility: In [1]:import pylab In [2]:pylab.linspace? Type: function Base Class: String Form: Namespace: Interactive File: /usr/local/lib/python2.5/site-packages/numpy/lib/function_base.py Definition: pylab.linspace(start, stop, num=50, endpoint=True, retstep=False) Docstring: Return evenly spaced numbers. Return num evenly spaced samples from start to stop. If endpoint is True, the last sample is stop. If retstep is True then return the step value used. Which shows that at present, the linspace supplied by pylab is actually the numeric version, not the mlab version. This is not at all obvious from looking at pylab.py! Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] cxx improvements
Christopher Barker wrote: >> http://www.artima.com/weblogs/viewpost.jsp?thread=95863 > > Thanks >> (It was in Mike's original message.) > > I must have missed that. Guido says: > > """ > I've yet to see an extension module using SWIG that doesn't make me > think it was a mistake to use SWIG instead of manually written wrappers. > The extra time paid upfront to create hand-crafted wrappers is gained > back hundredfold by time saved debugging the SWIG-generated code later. > """ > > hmm. wxPython is my prime example. I can't imagine that ever being done > enough to be useful without auto code generation. Period. Of course, > that doesn't apply to far smaller libraries. I agree with you that some form of automation is absolutely necessary for these large libraries. However, wxPython also proves, IMHO, that using SWIG specifically is no walk in the park. wxPython has put a lot of effort into patching bugs in SWIG (which never seem to make it into upstream SWIG), and writing complicated extensions and workarounds. It is not a silver bullet for reference counting -- wxPython has had reference counting bugs as recently as 2.8.3. In fact, since SWIG typemaps are required so often (which is just raw Python/C API code anyway), there are still opportunities to make reference counting bugs, and they are harder to track down since you're one step removed from the real code. > And many of the hand-written wrappers I've seen are nightmares of > incorrect reference counting. I think hand-wrapping is a just plain bad > idea, not when you have ctypes and pyrex and Boost (and CXX?) as options > instead. I'll have to respectfully disagree with your assessment of hand-wrapping. It is the least likely to become unsupported of any of these options, and the Python/C API has been reasonably stable over a number of revisions (certainly since new-style classes were introduced, at least), and is extremely well-documented. Cheers, Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mlab and pylab
Christopher Barker wrote: > Ryan May wrote: >>> I for one will be happy to change my code; numerical stuff in >>> numpy, plotting stuff in pylab (or pyplot?), though some things >>> like linspace() may be hard to loose; that's really an mlab >>> function and I can import mlab. > > I'm a big namespace fan. I'd much rather see us all do something like: > > import pyplot > import numpy as N > import mlab > > etc. > > In this case, there should be little name overlap between these modules, > and you could "import *" all of them if you really wanted. > > However, they are not all maintained by the same folks, so some overlap > may occur, and that's a good reason for keeping them in separate namespaces. > > In any case, it needs to be decided what the point of the mlab module > is. There was a discussion about this a few (quite a few!) years ago > when there was just Numeric, and it came with an mlab module (at least I > think it was called mlab). At that point, we decided that Matlab > compatibility wasn't really the point -- the point was that there were a > number of nifty utilities in Matlab that people missed, and that the > stuff in mlab wasn't completely Matlab compatible anyway (numpy and > Matlab are just plain different, after all). We more or less decided to > what we really needed was a "Utilities" module that could hold some of > those nifty useful functions (like linspace, etc), but not much was done > at the time. Since then, numpy as gained quite a bit of those features > anyway. > > So for this mlab module -- what is the goal? > > 1) A Matlab-like set of tools? In that case, it way want to default to > matrices, rather than arrays, etc. If that's what's wanted, I'd make it > a stand-alone module, that imports what it needs from numpy, but > provides a complete API. It looks like it started out something like this, but I don't think it should stay that way. If someone wants something like this, I think they will have to do it themselves. > > 2) A bunch of extra utilities that numpy doesn't have, but are handy. In > that case, I'd have it include only the extras, and one would need to > import numpy and mlab both. It could also "import *" numpy , then add > the extra stuff, but I'm too much of a namespace fan to advocate for > that. What happens when numpy adds a name that clashes with an mlab > name, for instance? I think this is the direction mlab has evolved, and my intention is to take it the rest of the way. As with pylab, some degree of matlab-similarity can be retained, but the goal is not a clone--that would be neither attainable nor desirable. If someone wants something more clone-like, they can use octave or scilab. I do not think mlab should "from numpy import *"; if that is what someone wants, they can do it explicitly themselves, very easily. Now, pylab should do something like "from mlab import *; from numpy import *; from pyplot import *", but mlab should be its own nice, clean set of functions. The strategy here is to make a clear distinction between modules that provide unique functionality, and modules that serve as namespace aggregators. Eric > > -Chris > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] cxx improvements
Eric Firing wrote: > Michael Droettboom wrote: >> I appreciate the way it fits so nicely into C++ ideas about RAII and >> exceptions -- but if you're not a C++ guy, that pro is probably a con. > What is RAII? "Resource Aquisition is Initialization" -- It's a C++ memory management technique where all resources are allocated in constructors and destroyed in destructors (I'm grossly oversimplifying). It allows memory management to be mostly hidden from the users of classes, and exceptions to work as they were intended (without lots of try/catch blocks everywhere.) RAII is not the solution to all memory management problems, of course, but it's a pretty common and important rule of thumb for C++. See here for more info: http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.18 PyCxx uses RAII to manage the lifetime of Python objects without requiring explicit reference counting. For instance, when you get a Py::Int from an argument, the reference count of its "owned" Python object is increased in the constructor and decreased in the destructor. So when the Py::Int goes out of scope, it automatically destroys its reference to the underlying Python object. In this way, I see pycxx less as a wrapper mechanism (like SWIG or even Boost), and more like C++ convenience and safety extensions to the regular Python/C API. Given my familiarity with the Python/C API, that could be why I like it. > I don't know how well pyrex will be maintained and updated, long-term. Which, of course, is one of the impetuses (impeti?) for moving away from CXX. We'll have to tread carefully. >> I suppose my initial disappointment in SWIG is that I like its >> fundamental idea -- of automating the tedious boilerplate -- but the >> execution of it just seems so heavyweight. But maybe that doesn't >> really matter. This is Python after all ;) > > I think it is a perfectly valid concern and consideration. Some benchmarking may be in order. I think it would be useful to know the difference in function call overhead between the different approaches, for instance. And overall memory usage is probably a secondary concern. Cheers, Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mlab and pylab
Eric Firing wrote: > I do not think mlab > should "from numpy import *"; if that is what someone wants, they can do > it explicitly themselves, very easily. Now, pylab should do something > like "from mlab import *; from numpy import *; from pyplot import *", > but mlab should be its own nice, clean set of functions. +1 -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
