I only took a brief look at that branch, but two comments 1) can you clean up your git history, you are adding 20k new lines (of mostly freetype and random files that should not be tracked) 2) can you split the propertify work up into chunks that are easier to review?
On Thu, Jul 31, 2014 at 7:16 AM, jamesramm <jamessr...@gmail.com> wrote: > It seens that discussion of properties has died off, but I see it as a very > important implementation for 2 reasons: > > 1. It will help with the implementation of stylsheets and a DOM-type model > as proposed in MEP25 and MEP26 > > 2. The act of working through the code to add properties exposes any > inconsistencies and vulnerabilities. > > I have been adding properties to my fork of MPL as part of the development > of a visualisation tool. > https://github.com/JamesRamm/matplotlib/tree/master/lib/matplotlib > > text.py and font-manager.py are completely 'propertyfied' and I have done a > fair amount of work on artist.py, _axes.py, _base.py and axis.py > > Axis.py in particular is a sticking point, which has been difficult to add > properties to. In any case, the fact that the Ticker() class exists points > to some problems with this part of the code in particular. Ticker holds > references too (or rather, the locator and formatter properties of Ticker) > the axis object, yet is initialised within the initialisation of the axis > class... > This can be a problem. > > Looking through ticker.py, it seems that in most places, the need for a > reference to axis is not necessary. > > Functions such as zoom and pan, which are within the Locator class in > ticker, should actually be implemented in axis.py (as I have in my fork) as > they have no dependency on Locator. > > Anyway, adding properties is a large job. I will probably implement them > completely as part of my work, but: > > - Backwards compatibility will be broken > - The resulting library will probably look a whole lot different to MPL. > > For those reasons, I doubt I will ever make a pull request for my fork and I > will neglect areas such as the pyplot/pylab interfaces. IMO, have a nice > simple, object oriented API negates the need for such interfaces and I am > not concerned with keeping a 'matlab-user' community happy... > > I don't see the API of MPL changing this much anytime soon (or anytime > really), but in order to keep up with newer libraries it probably should, > and should not be concerned about backwards compatibility when it does... > > > > -- > View this message in context: > http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43730.html > Sent from the matplotlib - devel mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Thomas Caswell tcasw...@gmail.com ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
