I'm moving this discussion over to mpl-dev. Its gettin too hairy for the more general audience.
On Friday 18 May 2007 12:02:30 pm Alexander Schmolck wrote: > If I may make another suggestion (I don't have time to volunteer for > implementing them in the forseeable future, but I might eventually if > there's interest): Maybe the way configuration is handled could be > improved: > > 1. It seems to me that letting users manipulate some raw dictionary > (`rcParams`) in order to customize behavior is bad. > > Just now, on my first dig into matplotlib I've found a number of bugs > that result from bad state in rcParams. As a user this has also caused me > some wasted time, because typos and other illegal param choices are not > caught early (but are relativley likely, because matplotlib has many and > complex options). > > Using some dedicated class-instance instead of a dict would allow for: > - automatic conistency checks on setting > - possibly even change propagation (likely faster and certainly less > error prone if done right: I'm not sure how many places rcParams dependent > results apart from the tex-stuff are cached and should be recomputed when > certain params change, but obviously an push/'event'-based solutin could be > faster than pull/polling) > - possibly better performance, because e.g. using immutable values would > allow identity based checks to see if a rcParam changed and obviate > the need to copy; > - convenient doc lookup and searching an display of available > alternatives (e.g. font-families etc) > - better factoring of the matplotlibrc parsing and validation see below: This sounds like a good proposal to me. Some other devs had considered using the traits package to address some of these points. Maybe they will comment. > 2. It also seems to me that having some custom config file format rather > than just (a literal-only subset of) python is suboptimal. Why make people > learn another and more limited syntax when python literals are already > familiar and both more powerful and easier to use If someone donated a nickel for every time I have seen this argument on the mailing list, we might have enough money to buy John a doughnut. > (e.g. the latex-preamble > setting can't express multiple package options, because param values can't > contain ',')? Thats a pretty big bug. See the disclaimer concerning preamble customizations :) > It would also get rid of the IMO undesirable coupling of > string-parsing and type-checking that the validate_* functions do at the > moment; really setting an rcParam should also do the latter but not the > former (and guaranteed validation on setting would also avoid the need > to sprinkle random checks on reading through the code). > > IMO it would be much nicer if there was some more declarative way to > specify options, check their validity on setting and assoicate docs with > them (sort of like e.g. emcs-custom vars). > > Valid files in the old-syntax could be translated automatically quite > easily, so I don't think it's a compatiblity issue. These are all good points, most of which have been brought up before. What we need is someone with sufficient time and motivation... Darren ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
