matplotlib-devel Mailing List for matplotlib

Fernando Garcia Bermudez, on 2011-02-03 09:14,  wrote:
> On Thu, Feb 3, 2011 at 06:05, Michael Droettboom <md...@st...> wrote:
> > On 02/03/2011 07:48 AM, Darren Dale wrote:
> >> On Thu, Feb 3, 2011 at 12:12 AM, Fernando Garcia Bermudez
> >> <mo...@gm...>  wrote:
> >>
> >>> Before continuing the debug process, though, I wanted to check with
> >>> someone knowledgeable of this branch regarding its current status. Is
> >>> it possible to compile matplotlib on python3?
> >>>
> >> Mike D. did some initial work for py3 support a while back. I don't
> >> know what platform he was working on, but he was able to produce a
> >> simple plot, maybe running the simple_plot demo.
> >>
> > I was working on Linux (RHEL5), and never got past that platform.
>
> I'll stay on the lookout for the github py3k branch and will do as
> suggested. Thanks for the update.
> 

By the way, there was a recent poll on python.org for packages
where users desire Python 3 support.  

Here are the top 10:

Votes | Package	
------+--------
 837  | Django 	
 454  | wxPython 	
 406  | scipy 	
 364  | matplotlib 	
 327  | PIL 	
 266  | py2exe 	
 185  | Twisted 	
 179  | PyGTK 	
 135  | Pygame 	
  94  | web2py 	

http://python.org/3kpoll

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

On Wed, Feb 16, 2011 at 1:21 PM, Maximilian Trescher
<fa...@tr...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi there,
>
> I just created my first patch for matplotlib, it's addressing bug 3176823.
>
> I send the patch with an example (as suggested in the faq).

A pull request has been filed at
https://github.com/matplotlib/matplotlib/pull/18 . The discussion at
the pull request brought to light an issue: the Axes.plot_date
docstring states that the "tz" kwarg should be None or a string, but
the actual implementation appears to require None or a tzinfo
instance, not a string. There does not appear to be any tests or
examples. Does anyone use the tz kwarg to plot_date? Should we change
the docstring to indicate that a tzinfo instance is required, or do we
extend the API to accept either a tzinfo instance (as currently
implemented) or a string (as currently documented)?

Darren

Here is a pull request proposing some changes to make.osx:
https://github.com/matplotlib/matplotlib/pull/17 . I have never used
make.osx myself. Could someone familiar with its use please have a
look and decide whether the changes should be accepted?

Thanks,
Darren

On Fri, Feb 25, 2011 at 3:16 PM, Eric Firing <ef...@ha...> wrote:
> On 02/25/2011 10:01 AM, John Hunter wrote:
>> On Fri, Feb 25, 2011 at 1:43 PM, Ryan May<rm...@gm...>  wrote:
>>> On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale<dsd...@gm...>  wrote:
>>>> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root<ben...@ou...>  wrote:
>>>>> Ok, I am still learning quite a bit about git, please bear with me.
>>>>>
>>>>> I am having difficulty completing a pull request that I opened.
>>>>
>>>> In general, I don't think we should close our own pull requests. It
>>>> short-circuits the review process.
>>>
>>> Agreed in principle. However, do we as devs want to get/give reviews
>>> on every change that fixes typos in the docs or fixes stupid bugs in
>>> examples? I think there's a point of diminishing returns.
>>
>> I just want to throw out there that in the migration to github, we
>> never officially said we were going to switch the development process.
>>   In fact, we said the opposite. After the migration,  Jarrod suggested
>> the pull request workflow as espoused in gitwash, and I am happy to
>> experiment with it, but only to the extent that "it works", ie we are
>> getting fast enough code reviews and pull requests closed that
>> development is slowed significantly.  In our experience on sf, we
>> weren't doing a good job keeping up with submitted requests by
>> non-developers on the trackers, much less reviewing the core devs'
>> contributions.  Let he who thinks they can keep up with MD and JJ step
>> forward...
>>
>> JDH
>
> Elaborating a bit: mpl historically has had a very loose management and
> a free approach to changes (Thanks, John!).  I think it has served us
> well.  The move to git permits a continuation of this style (though for
> a smaller set of committers), while facilitating more structured
> procedures; it doesn't force us to change, it makes it easier to use a
> range of styles, as appropriate, and perhaps gently nudges us towards
> more review prior to committing.
>
> As always, review is not a one-time opportunity.  Committed changes
> always can be reviewed, and new changes made as needed.
>
> This is evolution, not revolution.

I'll back off my assertion somewhat, and instead observe that, so far,
pull requests and associated code review have been working out
superbly. We are catching problems before they find their way into the
official repos. People are making constructive criticism, making
encouraging comments. Perhaps my original comment was too rigid, and
instead I should say that the pull request/code review workflow is
shaping up to be a really code thing, and I would like to advocate for
its continued use. Where appropriate. :)

On 02/25/2011 10:01 AM, John Hunter wrote:
> On Fri, Feb 25, 2011 at 1:43 PM, Ryan May<rm...@gm...>  wrote:
>> On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale<dsd...@gm...>  wrote:
>>> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root<ben...@ou...>  wrote:
>>>> Ok, I am still learning quite a bit about git, please bear with me.
>>>>
>>>> I am having difficulty completing a pull request that I opened.
>>>
>>> In general, I don't think we should close our own pull requests. It
>>> short-circuits the review process.
>>
>> Agreed in principle. However, do we as devs want to get/give reviews
>> on every change that fixes typos in the docs or fixes stupid bugs in
>> examples? I think there's a point of diminishing returns.
>
> I just want to throw out there that in the migration to github, we
> never officially said we were going to switch the development process.
>   In fact, we said the opposite. After the migration,  Jarrod suggested
> the pull request workflow as espoused in gitwash, and I am happy to
> experiment with it, but only to the extent that "it works", ie we are
> getting fast enough code reviews and pull requests closed that
> development is slowed significantly.  In our experience on sf, we
> weren't doing a good job keeping up with submitted requests by
> non-developers on the trackers, much less reviewing the core devs'
> contributions.  Let he who thinks they can keep up with MD and JJ step
> forward...
>
> JDH

Elaborating a bit: mpl historically has had a very loose management and 
a free approach to changes (Thanks, John!).  I think it has served us 
well.  The move to git permits a continuation of this style (though for 
a smaller set of committers), while facilitating more structured 
procedures; it doesn't force us to change, it makes it easier to use a 
range of styles, as appropriate, and perhaps gently nudges us towards 
more review prior to committing.

As always, review is not a one-time opportunity.  Committed changes 
always can be reviewed, and new changes made as needed.

This is evolution, not revolution.

Eric

On Fri, Feb 25, 2011 at 2:01 PM, John Hunter <jd...@gm...> wrote:

> On Fri, Feb 25, 2011 at 1:43 PM, Ryan May <rm...@gm...> wrote:
> > On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale <dsd...@gm...> wrote:
> >> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root <ben...@ou...> wrote:
> >>> Ok, I am still learning quite a bit about git, please bear with me.
> >>>
> >>> I am having difficulty completing a pull request that I opened.
> >>
> >> In general, I don't think we should close our own pull requests. It
> >> short-circuits the review process.
> >
> > Agreed in principle. However, do we as devs want to get/give reviews
> > on every change that fixes typos in the docs or fixes stupid bugs in
> > examples? I think there's a point of diminishing returns.
>
> I just want to throw out there that in the migration to github, we
> never officially said we were going to switch the development process.
>  In fact, we said the opposite. After the migration,  Jarrod suggested
> the pull request workflow as espoused in gitwash, and I am happy to
> experiment with it, but only to the extent that "it works", ie we are
> getting fast enough code reviews and pull requests closed that
> development is slowed significantly.  In our experience on sf, we
> weren't doing a good job keeping up with submitted requests by
> non-developers on the trackers, much less reviewing the core devs'
> contributions.  Let he who thinks they can keep up with MD and JJ step
> forward...
>
> JDH
>

I did a pull request for this minor change because I am still learning the
ins and outs of git and decided to make this commit in the manner I was
already familiar.

My feeling is that these pull requests are a great way to group various
commits into logical chunks.  It also makes for a good "paper" trail for all
changes.  Github provides so many useful tools surrounding them that making
direct merges without them seems almost disruptive.  I am worried that
having two different workflows may cause issues down the line.

My take is that pull requests should always be done, but we should leave it
to the discretion of the core developers whether or not they can
self-close.  This is not too different from how things were done on SF.  I
personally would send out an email for more significant changes, wait a
week, do a ping, and then self-commit if there were no comments.  For typos
and such, I did not even bother asking for reviews (although this was rare).

Just my two cents,
Ben Root

P.S. - Darren, my hat is off to you for all your work lately.  I can't thank
you enough.

On Fri, Feb 25, 2011 at 12:01 PM, John Hunter <jd...@gm...> wrote:
> I just want to throw out there that in the migration to github, we
> never officially said we were going to switch the development process.
>  In fact, we said the opposite. After the migration,  Jarrod suggested
> the pull request workflow as espoused in gitwash, and I am happy to
> experiment with it, but only to the extent that "it works", ie we are
> getting fast enough code reviews and pull requests closed that
> development is slowed significantly.  In our experience on sf, we
> weren't doing a good job keeping up with submitted requests by
> non-developers on the trackers, much less reviewing the core devs'
> contributions.  Let he who thinks they can keep up with MD and JJ step
> forward...

One comment from the peanut gallery: what we've found in ipython is
that the git pull request system does make the review process vastly
more efficient.  The tool is good enough that we've been reviewing
things pretty quickly, and it does overall help the project's code
quality quite a bit.  It makes a big difference if doing a review has
high overhead or if it's just a matter of clicking on a link, having
all the information nicely presented there for you (conversation,
files changed, highlighted diff), and being able to comment in 2
minutes.

For simple things often my review amounts to 'good job, merge away but
fix this little thing I commented on inline'.  It takes me 2 minutes
to do it, I manage to get in some feedback that improves the code
before merge, and I don't even ever download the actual branch, since
I do all the reviewing (for simple ones) just from the diffs on the
github pages.

Cheers,

f

Yo,

On Fri, Feb 25, 2011 at 12:02 PM, Fernando Perez <fpe...@gm...> wrote:
> On Fri, Feb 25, 2011 at 11:48 AM, Darren Dale <dsd...@gm...> wrote:
>> On Fri, Feb 25, 2011 at 2:43 PM, Ryan May <rm...@gm...> wrote:
>
>>> Agreed in principle. However, do we as devs want to get/give reviews
>>> on every change that fixes typos in the docs or fixes stupid bugs in
>>> examples? I think there's a point of diminishing returns.
>>
>> I agree. Hence the "in general" qualification.
>
> FWIW, my take on this question from the same conversation on
> ipython-dev a few days ago:
>
> http://mail.scipy.org/pipermail/ipython-dev/2011-February/007258.html
>
> Others seemed OK with that approach.

In nipy, we really haven't got into the swing of code review, but I
see sympy going for it with enthusiasm, and they're better than us :)

Our policy thus far has been:

doc changes : go for it
small bug fix with test : use judgment, probably go for it
anything else : post and ask for review.  In general (TM).  No review,
after some period, perhaps with reminder, go for it.

It may not be very obvious, but the wait-for-review step has far less
inconvenient consequences using git than svn because it's so easy to
merge, rebase and so on.

(lurking now resumed),

Matthew

On Fri, Feb 25, 2011 at 11:48 AM, Darren Dale <dsd...@gm...> wrote:
> On Fri, Feb 25, 2011 at 2:43 PM, Ryan May <rm...@gm...> wrote:

>> Agreed in principle. However, do we as devs want to get/give reviews
>> on every change that fixes typos in the docs or fixes stupid bugs in
>> examples? I think there's a point of diminishing returns.
>
> I agree. Hence the "in general" qualification.

FWIW, my take on this question from the same conversation on
ipython-dev a few days ago:

http://mail.scipy.org/pipermail/ipython-dev/2011-February/007258.html

Others seemed OK with that approach.

HTH,

f

On Fri, Feb 25, 2011 at 1:43 PM, Ryan May <rm...@gm...> wrote:
> On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale <dsd...@gm...> wrote:
>> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root <ben...@ou...> wrote:
>>> Ok, I am still learning quite a bit about git, please bear with me.
>>>
>>> I am having difficulty completing a pull request that I opened.
>>
>> In general, I don't think we should close our own pull requests. It
>> short-circuits the review process.
>
> Agreed in principle. However, do we as devs want to get/give reviews
> on every change that fixes typos in the docs or fixes stupid bugs in
> examples? I think there's a point of diminishing returns.

I just want to throw out there that in the migration to github, we
never officially said we were going to switch the development process.
 In fact, we said the opposite. After the migration,  Jarrod suggested
the pull request workflow as espoused in gitwash, and I am happy to
experiment with it, but only to the extent that "it works", ie we are
getting fast enough code reviews and pull requests closed that
development is slowed significantly.  In our experience on sf, we
weren't doing a good job keeping up with submitted requests by
non-developers on the trackers, much less reviewing the core devs'
contributions.  Let he who thinks they can keep up with MD and JJ step
forward...

JDH

On Fri, Feb 25, 2011 at 1:48 PM, Darren Dale <dsd...@gm...> wrote:
> On Fri, Feb 25, 2011 at 2:43 PM, Ryan May <rm...@gm...> wrote:
>> On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale <dsd...@gm...> wrote:
>>> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root <ben...@ou...> wrote:
>>>> Ok, I am still learning quite a bit about git, please bear with me.
>>>>
>>>> I am having difficulty completing a pull request that I opened.
>>>
>>> In general, I don't think we should close our own pull requests. It
>>> short-circuits the review process.
>>
>> Agreed in principle. However, do we as devs want to get/give reviews
>> on every change that fixes typos in the docs or fixes stupid bugs in
>> examples? I think there's a point of diminishing returns.
>
> I agree. Hence the "in general" qualification.
>

Sorry. Glossed over that and took you mentioning it in this context as
objecting to self-merging this particular set of simple changes.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Feb 25, 2011 at 2:43 PM, Ryan May <rm...@gm...> wrote:
> On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale <dsd...@gm...> wrote:
>> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root <ben...@ou...> wrote:
>>> Ok, I am still learning quite a bit about git, please bear with me.
>>>
>>> I am having difficulty completing a pull request that I opened.
>>
>> In general, I don't think we should close our own pull requests. It
>> short-circuits the review process.
>
> Agreed in principle. However, do we as devs want to get/give reviews
> on every change that fixes typos in the docs or fixes stupid bugs in
> examples? I think there's a point of diminishing returns.

I agree. Hence the "in general" qualification.

On Fri, Feb 25, 2011 at 1:11 PM, Darren Dale <dsd...@gm...> wrote:
> On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root <ben...@ou...> wrote:
>> Ok, I am still learning quite a bit about git, please bear with me.
>>
>> I am having difficulty completing a pull request that I opened.
>
> In general, I don't think we should close our own pull requests. It
> short-circuits the review process.

Agreed in principle. However, do we as devs want to get/give reviews
on every change that fixes typos in the docs or fixes stupid bugs in
examples? I think there's a point of diminishing returns.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Feb 25, 2011 at 1:45 PM, Benjamin Root <ben...@ou...> wrote:
> Ok, I am still learning quite a bit about git, please bear with me.
>
> I am having difficulty completing a pull request that I opened.

In general, I don't think we should close our own pull requests. It
short-circuits the review process.

> When I try
> to merge the changes to upstream, they get rejected.  I can merge it back to
> my own master, and can even push it up to my github repo's master, but not
> matplotlib's master.
>
> After some investigation, I am left wondering if the cause might be that my
> branches were branched off of my (un-updated) master (which tracked my
> github's master, not matplotlib's master).  I have tried rebasing my
> branches, but that doesn't seem to solve the problem.
>
> I am thoroughly confused.  Anybody has ideas?  Should I dump my repos and
> start fresh?

No, don't do that. Which repository are you trying to push to? You
probably need to sync up with the remote. See the discussion on "git
push" at the end of http://gitref.org/remotes/

Ok, I am still learning quite a bit about git, please bear with me.

I am having difficulty completing a pull request that I opened.  When I try
to merge the changes to upstream, they get rejected.  I can merge it back to
my own master, and can even push it up to my github repo's master, but not
matplotlib's master.

After some investigation, I am left wondering if the cause might be that my
branches were branched off of my (un-updated) master (which tracked my
github's master, not matplotlib's master).  I have tried rebasing my
branches, but that doesn't seem to solve the problem.

I am thoroughly confused.  Anybody has ideas?  Should I dump my repos and
start fresh?

Thanks,
Ben Root

Hello all,

I have started to take seriously a refactor of mplot3d.  It won't be
something done overnight or anything, but I want to do it piece-meal.  The
first step will be to create some 3d versions of the various 2d transform
classes in transforrms.py.  I am not a Transforms guru, so I would greatly
appreciate any input from those who really understand its architecture.

For example, should my 3D transform classes be derived from their 2d
counter-parts, or should it be a separate branch off of the base classes?
Another thought I have had is that I would like to be able to mix-in
existing transforms and scales to create a new transform (similar to
blendedtransforms).  For example, a CylinderTransform could be created by
mixing in the Polar transform with a regular linear scale.  Another example
would be to take a geo transform and add a log scale for its z-axis (this
would be a nice prospect for graphing meteorological data with basemap).

So, Transforms gurus, what do you suggest?  Are there existing attempts to
create 3D transforms that I can learn from?  What about the prospect of
incompatibilities with 2D transforms?

Thanks,
Ben Root