matplotlib-devel Mailing List for matplotlib

I would suggest create a new branch, though. You can create a new branch
from the old one, then make your changes there. That way if you mess up
something you still have the original to fall back on.
On Thu, Jul 31, 2014 at 5:15 PM, Thomas Caswell <tca...@gm...> wrote:
> Git lets you re-write history pretty extensively. If you use a tool
> on top of git (I use magit in emacs) you can selectively commit hunks
> one or two at a time. At a minimum split it up by file. You are
> going to have to do some force-pushing anyway.
>
> Making the PRs as small as reasonable makes reviewing much easier. It
> makes it possible to go through the entire PR in one sitting and it
> allows the un-controversial stuff to be merged as quickly as possible
> without being held up by other parts. The longer large PRs hang
> around the greater the chance they will accumulate conflicts with
> other PRs and require a re-base (re-basing a 500+ line diff is
> _incredibly_ painful).
>
> Tom
>
> On Thu, Jul 31, 2014 at 11:09 AM, jamesramm <jam...@gm...> wrote:
> > Thomas Caswell wrote
> >> 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?
> >
> > Yes. This is mostly my inability to use git (I've not particular used it
> > before). I'll have to look up how to clean the history and 'unversion'
> the
> > unneeded freetype stuff.
> >
> > As it is already committed to my branch, im not sure the existing stuff
> can
> > be split into chunks? But I will make issues and split up the next lumps
> of
> > work.
> >
> > I'll post back when it is (hopefully) cleaner
> >
> >
> >
> > --
> > View this message in context:
> http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43732.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
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> --
> Thomas Caswell
> tca...@gm...
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Git lets you re-write history pretty extensively. If you use a tool
on top of git (I use magit in emacs) you can selectively commit hunks
one or two at a time. At a minimum split it up by file. You are
going to have to do some force-pushing anyway.
Making the PRs as small as reasonable makes reviewing much easier. It
makes it possible to go through the entire PR in one sitting and it
allows the un-controversial stuff to be merged as quickly as possible
without being held up by other parts. The longer large PRs hang
around the greater the chance they will accumulate conflicts with
other PRs and require a re-base (re-basing a 500+ line diff is
_incredibly_ painful).
Tom
On Thu, Jul 31, 2014 at 11:09 AM, jamesramm <jam...@gm...> wrote:
> Thomas Caswell wrote
>> 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?
>
> Yes. This is mostly my inability to use git (I've not particular used it
> before). I'll have to look up how to clean the history and 'unversion' the
> unneeded freetype stuff.
>
> As it is already committed to my branch, im not sure the existing stuff can
> be split into chunks? But I will make issues and split up the next lumps of
> work.
>
> I'll post back when it is (hopefully) cleaner
>
>
>
> --
> View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43732.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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...

Thomas Caswell wrote
> 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?
Yes. This is mostly my inability to use git (I've not particular used it
before). I'll have to look up how to clean the history and 'unversion' the
unneeded freetype stuff. 
As it is already committed to my branch, im not sure the existing stuff can
be split into chunks? But I will make issues and split up the next lumps of
work.
I'll post back when it is (hopefully) cleaner
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43732.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

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 <jam...@gm...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...

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.