matplotlib-devel Mailing List for matplotlib (Page 3)

On 2/25/2011 4:03 PM, Benjamin Root wrote:
>
>
> On Fri, Feb 25, 2011 at 5:11 PM, Paul Ivanov <piv...@gm...
> <mailto:piv...@gm...>> wrote:
>
> Fernando Garcia Bermudez, on 2011年02月03日 09:14, wrote:
> > On Thu, Feb 3, 2011 at 06:05, Michael Droettboom <md...@st...
> <mailto: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... <mailto: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
> <http://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
>
>
>
> Which just goes to show that some people don't understand
> dependencies... (PIL and PyGTK are needed by matplotllib to be fully
> py3k compatible). Hopefully this will light a fire for them as well.
>
> Ben Root
>
Are PIL and PyGTK holding back matplotlib for Python 3?
I have a private port of PIL 1.1.7 for Python 3 that is passing all 
tests on Windows <http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil> and 
works well with a couple of other third party libraries (e.g. scipy, 
biopython). Official Python 3 support is planned for PIL 1.2 
<http://mail.python.org/pipermail/image-sig/2011-January/006650.html>.
As for PyGTK, there will likely never be an official version for Python 
3: "PyGtk 2.24 will be the last release in the PyGtk series. ... New 
users wising to develop Python applications using GTK are recommended to 
use the GObject-Introspection features available in PyGObject." 
<http://mail.gnome.org/archives/gnome-announce-list/2011-February/msg00046.html>.
It seems that wxPython, in its current form, will also not be available 
for Python 3. Python 3 support is planned for the "Next Generation" 
<http://wiki.wxpython.org/TentativeRoadmap>. There is a private port of 
wxPython 2.9.x for Python 3 
<http://groups.google.com/group/wxPython-dev/browse_thread/thread/49701177b0a72c6f>. 
I have never gotten it to run reliable.
Are there plans for matplotlib to drop Python 2.4 and 2.5? This would 
make porting to Python 3 much easier.
Christoph

Benjamin Root, on 2011年02月25日 18:03, wrote:
> On Fri, Feb 25, 2011 at 5:11 PM, Paul Ivanov <piv...@gm...> wrote:
> > 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
> 
> Which just goes to show that some people don't understand dependencies...
> (PIL and PyGTK are needed by matplotllib to be fully py3k compatible).
> Hopefully this will light a fire for them as well.
Well, this was a user poll - users shouldn't have to know or 
express all of the dependencies for a given package that they use
- that's for us package developers to figure out. 
To quote from the poll conclusions:
 What does this poll mean?
 
 Off-hand, nothing: nominating a package will not mean that its
 authors now start porting it to Python 3.
 
 However, we still hope that this still has some effect on the
 Python community:
 
 * Volunteers trying to help now see where help is most wanted
 * Package authors now see that there really is (or is not)
 demand for getting their package ported.
It's that last point that I was trying to highlight for us, as
matplotlib was the fourth most nominated package for py3k
support.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

On Fri, Feb 25, 2011 at 5:11 PM, Paul Ivanov <piv...@gm...> wrote:
> 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
>
Which just goes to show that some people don't understand dependencies...
(PIL and PyGTK are needed by matplotllib to be fully py3k compatible).
Hopefully this will light a fire for them as well.
Ben Root

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

On Wed, Feb 23, 2011 at 10:18 PM, Darren Dale <dsd...@gm...> wrote:
> On Sun, Feb 20, 2011 at 10:22 PM, Darren Dale <dsd...@gm...> wrote:
> > On Sat, Feb 19, 2011 at 1:43 PM, Darren Dale <dsd...@gm...> wrote:
> >> On Sat, Feb 19, 2011 at 1:03 PM, Jarrod Millman <mi...@be...>
> wrote:
> >>> On Fri, Feb 18, 2011 at 8:55 PM, Darren Dale wrote:
> >>>> * Jarrod offered to contribute to the docs to describe the recommended
> >>>> workflow.
> >>>
> >>> I did a first pass at changing the documentation from describing svn
> >>> to git (including adding gitwash) and generated a pull request:
> >>> https://github.com/matplotlib/matplotlib/pull/3
> >>
> >> Lets continue discussion at the pull request.
> >
> > We had some conflicting changes, but Jarrod graciously closed pull
> > request 3 without merging and reapplied the gitwash docs to the branch
> > at pull request 2. We could use some more eyes on that branch to
> > ensure the docs are current. Any help would be appreciated, please
> > direct feedback to https://github.com/matplotlib/matplotlib/pull/2 .
>
> I just pushed the documentation up to the matplotlib.github.com repo,
> so we can see whether we like hosting the docs at
> matplotlib.github.com. The first push was pretty slow, 100 KB/s. The
> docs are 80 MB.
>
> Anyway, the documentation for working with git and github is currently
> available at http://matplotlib.github.com/devel/gitwash/index.html
>
> Darren
>
>
Just a few things I noticed. First, the front page states that v1.0.0 is
available for download, instead of v1.0.1. Second, the link for the
changelog is broken (points to:
http://matplotlib.github.com/_static/CHANGELOG). So far, everything else
looks fine.
Ben Root

On Sun, Feb 20, 2011 at 10:22 PM, Darren Dale <dsd...@gm...> wrote:
> On Sat, Feb 19, 2011 at 1:43 PM, Darren Dale <dsd...@gm...> wrote:
>> On Sat, Feb 19, 2011 at 1:03 PM, Jarrod Millman <mi...@be...> wrote:
>>> On Fri, Feb 18, 2011 at 8:55 PM, Darren Dale wrote:
>>>> * Jarrod offered to contribute to the docs to describe the recommended
>>>> workflow.
>>>
>>> I did a first pass at changing the documentation from describing svn
>>> to git (including adding gitwash) and generated a pull request:
>>> https://github.com/matplotlib/matplotlib/pull/3
>>
>> Lets continue discussion at the pull request.
>
> We had some conflicting changes, but Jarrod graciously closed pull
> request 3 without merging and reapplied the gitwash docs to the branch
> at pull request 2. We could use some more eyes on that branch to
> ensure the docs are current. Any help would be appreciated, please
> direct feedback to https://github.com/matplotlib/matplotlib/pull/2 .
I just pushed the documentation up to the matplotlib.github.com repo,
so we can see whether we like hosting the docs at
matplotlib.github.com. The first push was pretty slow, 100 KB/s. The
docs are 80 MB.
Anyway, the documentation for working with git and github is currently
available at http://matplotlib.github.com/devel/gitwash/index.html
Darren

On Tuesday, February 22, 2011, Gökhan Sever <gok...@gm...> wrote:
>
>
> On Tue, Feb 22, 2011 at 3:00 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> Doesn't Perl5 let you completely restructure its syntax? And bash does have me typing "fi" everywhere...
>
> Ben Root
>
>
> I was thinking to use a variable name of "değişken" instead of "variable". Can Perl5 allow this? Isn't that "fi" just for closing match to the "if" in bash?
>
> --
> Gökhan
>
I see we need an international symbol for sarcasm. Any suggestions?
Ben Root

On Tue, Feb 22, 2011 at 3:00 PM, Benjamin Root <ben...@ou...> wrote:
>
>> Doesn't Perl5 let you completely restructure its syntax? And bash does
> have me typing "fi" everywhere...
>
> Ben Root
>
I was thinking to use a variable name of "değişken" instead of "variable".
Can Perl5 allow this? Isn't that "fi" just for closing match to the "if" in
bash?
-- 
Gökhan

On Tue, Feb 22, 2011 at 3:27 PM, Gökhan Sever <gok...@gm...> wrote:
>
>
> On Tue, Feb 22, 2011 at 12:45 PM, Benjamin Root <ben...@ou...> wrote:
>
>> Hello all,
>>
>> Given some recent -- ahem -- difficulties with matplotlib users where
>> English is not their native language, it has dawned on me that maybe we
>> ought to consider making available translated versions of our
>> documentation. I have absolutely no experience with such efforts, but I did
>> see that Sphinx does support internationalization:
>>
>> http://sphinx.pocoo.org/latest/intl.html
>>
>> and I do believe we have some bilingual developers on this list (or at
>> least are active on the users list). While I don't think it would be
>> possible to translate the API docs effectively, at the very least we should
>> be able to provide translations of other parts.
>>
>> What does everyone think? Could someone who has done internationalization
>> (particularly using sphinx) comment? What languages would we like the docs
>> to be in?
>>
>> Ben Root
>>
>
>
I think Eric had the best point against internationalization:
I think this is premature. My sense is that there are other aspects of
> the docs and code that should be cleaned up first, and that having
> translations of the docs will actually make this more difficult--there
> will be more pieces of the system to try to keep up to date
>
I definitely do agree with Paul's point
English being lingua franca ;) is fairly typical in the software
world, but that doesn't mean we should feel free to sprinkle
idioms and confusing cultural references everywhere. I'm guilty
of both of these, as I sometimes try to add "color" to my
comments, which might produce a chuckle for the folks who
understood, but be a source of unneeded confusion for others.
I guess I was thinking more along the lines of enabling translation
contributions from users as opposed to devoting core development resources
to translation. In other words, does it take more than just enabling some
options and modifying the doc directory tree to then allow anybody to
provide a translated version of a page?
I think working on adding new features into mpl and making sure that its a
> bug-free library are better investments instead of spending time on
> providing translated documents. Google translate gives a funny but still
> useful translation in my native language :)
>
> Anyways, is there any programming language out or plans for Python that
> provides syntax for non-English languages?
>
>
Doesn't Perl5 let you completely restructure its syntax? And bash does have
me typing "fi" everywhere...
Ben Root

On Tue, Feb 22, 2011 at 12:45 PM, Benjamin Root <ben...@ou...> wrote:
> Hello all,
>
> Given some recent -- ahem -- difficulties with matplotlib users where
> English is not their native language, it has dawned on me that maybe we
> ought to consider making available translated versions of our
> documentation. I have absolutely no experience with such efforts, but I did
> see that Sphinx does support internationalization:
>
> http://sphinx.pocoo.org/latest/intl.html
>
> and I do believe we have some bilingual developers on this list (or at
> least are active on the users list). While I don't think it would be
> possible to translate the API docs effectively, at the very least we should
> be able to provide translations of other parts.
>
> What does everyone think? Could someone who has done internationalization
> (particularly using sphinx) comment? What languages would we like the docs
> to be in?
>
> Ben Root
>
I think working on adding new features into mpl and making sure that its a
bug-free library are better investments instead of spending time on
providing translated documents. Google translate gives a funny but still
useful translation in my native language :)
Anyways, is there any programming language out or plans for Python that
provides syntax for non-English languages?
-- 
Gökhan