> > Simson> 3. If I was going to make a major change to the API at > Simson> this point, it would be to make it so that you don't have > Simson> a class/function/ identifier called "axes" and another one > Simson> called "axis." I frequently get confused between these two > Simson> words; I imagine that non-native English speakers get > Simson> confused even more frequently. Irregular noun plurals in > Simson> English are confusing, and it probably isn't necessary to > Simson> use both. One approach would be to never allow "axis," to > Simson> only allow "xaxis" and "yaxis" and perhaps something > Simson> (either_axis?) for the abstract super-class, but this may > Simson> be a bigger change than you wish to consider at the > Simson> present time. > > Yes, this is a confusing and poor nomenclature. We're probably stuck > with it at this point, since it fairly deeply ingrained.
It's never to late to change something. For any successful project, there will always be more users in the future than in the past. The key thing is to make the change without breaking backwards compatibility. But that's not hard: you can accept the old value while nevertheless standardizing on the new one. > > Simson> Ah, the matplotlibrc file. It seems that you are trying > Simson> to do too much with this file. Is the point of the file > Simson> to have default graphing behavior, or to have site-wide > Simson> configuration information? You may wish to split the file > Simson> into two parts --- a config part and a graphing > Simson> preferences part --- because it seems that sometimes > Simson> people wish to change one without changing the other. Or > Simson> you may want to have explicit inheritance --- like an > Simson> "-include" feature so that a local file can just shadow > Simson> some variables and then include the master file. I > Simson> understand that this can be done with a few lines of > Simson> python at the top of a program. Of course, given that > Simson> option, you may wish to do away with the local files > Simson> entirely. I'm not sure. > > The rc file is meant to support local customization, and directory > specific files are meant to support project specific customizations. > The idea here is: you may want a general configuration for most plots, > interactive plotting, etc, but you may want something entirely > different for a directory which contains a figure for a journal > article: PS backend, latex text, larger fontsizes, thicker lines... The problem with the RC file this way, though, is that I can give you a pice of python code and it will plot differently on your computer than on mine because of a change in your rc file. If you think that's okay, then it's okay. You're the designer, not me! But it is clearly a concern that I would have. > > The current implementation certainly has some limitations: we'd prefer > the file to be python rather than our own yet-another-rc-file-markup > and yes, we'd like to support includes and overrides with a basic > inheritance and namespace support, which we would get for free by > simply making the rc file python. This is an idea waiting to be > implemented. We'd probably borrow some work from recent changes to > ipython which were implemented to solve some of the same problems. > > Simson> Have the matplotlib developers put together a roadmap of > Simson> their directions that they want to take this project? > > http://matplotlib.sf.net/goals.html Thanks! > > though it is not updated as often as it should be and is not > entirely current. > > JDH > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
