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 wrote:
> Git lets you re-write history pretty
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 r
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
> revi
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:
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
incons
Hi matplotlib-devs,
I just added an alternate proposal to MEP13 (scroll to the bottom):
https://github.com/matplotlib/matplotlib/wiki/MEP13
which suggests that axes methods mirror the names of pyplot functions just
so it's easier to switch between the two. We could maintain the current
interface
On Thu, Jan 17, 2013 at 6:33 AM, Todd wrote:
> On Thu, Jan 17, 2013 at 11:30 AM, Todd wrote:
>
>> On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson wrote:
>>
>>> Hi Todd,
>>>
>>> I agree with the principle of properties - it will make much of the mpl
>>> codebase (and user code) more pythonic, so tha
On Thu, Jan 17, 2013 at 11:30 AM, Todd wrote:
> On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson wrote:
>
>> Hi Todd,
>>
>> I agree with the principle of properties - it will make much of the mpl
>> codebase (and user code) more pythonic, so thanks for proposing this.
>>
>> Would you be able to give
On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson wrote:
> Hi Todd,
>
> I agree with the principle of properties - it will make much of the mpl
> codebase (and user code) more pythonic, so thanks for proposing this.
>
> Would you be able to give an example of how you propose setters such as
> Axes.set
Hi Todd,
I agree with the principle of properties - it will make much of the mpl
codebase (and user code) more pythonic, so thanks for proposing this.
Would you be able to give an example of how you propose setters such as
Axes.set_xlim might make use of properties. The particular example I have
I have created a very preliminary MEP for the possible move to properties:
https://github.com/matplotlib/matplotlib/wiki/MEP13
Please take a look at it and discuss. As I said, this is very
preliminary. Everything is subject to change.
11 matches
Mail list logo
