matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[todd r. <tod...@gm...>]

On Wed, Oct 3, 2012 at 6:20 PM, Michael Droettboom <md...@st...> wrote:
> I invite comments for a new MEP about improving the situation with respect
> to our bundling of third-party Python dependencies.
>
> In particular, I'd love feedback from the various stakeholders -- those
> producing binary installers and packages for the various platforms.
>
> https://github.com/matplotlib/matplotlib/wiki/MEP11
>
> Mike

I help with the openSUSE packaging of mpl.  At least as openSUSE
policies go, bundling dependencies is considered a big no-no.  RPM has
its own dependency handling, so as long as the dependencies are
documented (ideally with version numbers) then there is no issue,
either at build-time or at run-time.  I think that would likely be the
case for any official linux packages.

Anyone on Linux who is trying to install matplotlib from source should
be prepared to handle dependency resolution manually.  If they aren't,
then they shouldn't be messing with package installation in the first
place.  I think the documentation should clearly state this, although
more diplomatically of course :)

So from a Linux standpoint I think bundling is a bad idea.  Further,
any solution should be prepared to handle the situation where the
dependencies are already available, and not try to download them under
this situation.  It should also be able to handle installation with no
internet connection as long as the dependencies are available, so it
can be compatible with automated build systems and hpc environments
which may not support internet access for security reasons.

For windows, rather than creating independent matplotlib installers,
can't the documentation just point people in the direction of a
pre-existing bundle like python(x,y)?  Since there are groups
dedicated to making it easy to install python packages on windows, I
don't see the point of going through all the trouble of making your
own version.  If you really wanted to you might even be able to use
their sources to create your own variant that just installs what you
need.

-Todd

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Chris B. <chr...@no...>]

On Wed, Oct 3, 2012 at 10:36 PM, Erik Bray <eri...@gm...> wrote:
> So as you wrote in the MEP, Numpy will simply have to be installed
> separately, I think, if the C++ modules require the Numpy headers.

Which is totally fine -- MPL requires a bunch of non-python
dependencies (OK, a few) anyway, so no matter how you slice it, you
need to get some stuf set up before you can build MPL.

Ideally, no on e needs to build MPL that would have trouble with this
requirement -- that's what binaries (and nifty linux .deb / .rpm ) are
for.

I personally prefer that dependencies are well documented, but not
necessarily auto-installed -- the auto stuff is just not reliable
enough.

-Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Thomas K. <th...@kl...>]

On 3 October 2012 22:08, Christoph Gohlke <cg...@uc...> wrote:
> Concerning end user experience, the scipy-stack project seems like a
> better place to address this.

To expand on this, there's a discussion underway on the scipy-user and
numfocus mailing lists about standardising a set of packages making up
the 'scipy stack', and pointing people to distributions which ship all
of those.

Matplotlib is of course among that set of packages, so hopefully that
will reduce the need for users to install it separately.

Thanks,
Thomas

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Erik B. <eri...@gm...>]

On Wed, Oct 3, 2012 at 9:10 PM, Michael Droettboom <md...@st...> wrote:
> On 10/03/2012 05:26 PM, Erik Bray wrote:
>> On 10/03/2012 12:20 PM, Michael Droettboom wrote:
>>> I invite comments for a new MEP about improving the situation with
>>> respect to our bundling of third-party Python dependencies.
>>>
>>> In particular, I'd love feedback from the various stakeholders -- those
>>> producing binary installers and packages for the various platforms.
>>>
>>> https://github.com/matplotlib/matplotlib/wiki/MEP11
>>>
>>> Mike
>>
>> +1 Let me know if you need/want any help with any distribute or pip
>> intricacies.
>>
>> As for Windows, I need to double check, but I believe bdist_wininst
>> installers generated by setuptools/distribute do support installing
>> dependencies from PyPI.
>>
>> Regarding Numpy: I'm not sure, does Matplotlib require Numpy at build
>> time?  I'm guessing probably yes, but if not it can also be installed
>> by easy_install or pip.  IIRC easy_install will install one of the
>> pre-built binary eggs.  pip only installs/builds from source which can
>> be problematic sometimes. Though I fixed Numpy a while back to be
>> installable by pip so it *does* work so long as Numpy can be built on
>> your system.
>
> Numpy is required at build time (matplotlib C++ extensions need to
> include Numpy's headers), but I had assumed if it was a requirement, it
> would get installed first and then we'd be ok to proceed.  Is that not
> how pip works?
>
> Mike

Yes/no.  Pip does install dependencies first, but they aren't
available at run-time of the setup.py of the dependent
package--unfortunate but mostly true.  I've been meaning to see if I
can fix that.  And easy_install of course is flawed in that it
installs dependencies afterwards. easy_install does support
setup_requires for downloading and adding packages to the path when
running setup.py, but this does *not* work with Numpy.

So as you wrote in the MEP, Numpy will simply have to be installed
separately, I think, if the C++ modules require the Numpy headers.

Erik

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Michael D. <md...@st...>]

On 10/03/2012 05:26 PM, Erik Bray wrote:
> On 10/03/2012 12:20 PM, Michael Droettboom wrote:
>> I invite comments for a new MEP about improving the situation with
>> respect to our bundling of third-party Python dependencies.
>>
>> In particular, I'd love feedback from the various stakeholders -- those
>> producing binary installers and packages for the various platforms.
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP11
>>
>> Mike
>
> +1 Let me know if you need/want any help with any distribute or pip 
> intricacies.
>
> As for Windows, I need to double check, but I believe bdist_wininst 
> installers generated by setuptools/distribute do support installing 
> dependencies from PyPI.
>
> Regarding Numpy: I'm not sure, does Matplotlib require Numpy at build 
> time?  I'm guessing probably yes, but if not it can also be installed 
> by easy_install or pip.  IIRC easy_install will install one of the 
> pre-built binary eggs.  pip only installs/builds from source which can 
> be problematic sometimes. Though I fixed Numpy a while back to be 
> installable by pip so it *does* work so long as Numpy can be built on 
> your system.

Numpy is required at build time (matplotlib C++ extensions need to 
include Numpy's headers), but I had assumed if it was a requirement, it 
would get installed first and then we'd be ok to proceed.  Is that not 
how pip works?

Mike

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Damon M. <dam...@gm...>]

On Wed, Oct 3, 2012 at 10:08 PM, Christoph Gohlke <cg...@uc...> wrote:
> On 10/3/2012 9:20 AM, Michael Droettboom wrote:
>> I invite comments for a new MEP about improving the situation with
>> respect to our bundling of third-party Python dependencies.
>>
>> In particular, I'd love feedback from the various stakeholders -- those
>> producing binary installers and packages for the various platforms.
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP11
>>
>> Mike

> I think that matplotlib, the library, should not attempt to work around
> Python's distribution/packaging limitations. Please do not use
> post-install or run-time scripts to detect and install missing
> dependencies.

I whole-heartedly agree here. There are package managers for this job.
I understand there are people less package-literate and, as you point
out below, the development team for each separate dependency can ship
a binary. Though I understand not all do this.

> Optionally, for Windows users that won't touch pip or easy_install (like
> me), matplotlib could provide separate downloads of installers for
> dateutil, pytz, pyparsing, and six. They are trivial to create.

> Also consider a separate package for the matplotlib tests, which would
> include 35 MB of baseline images that are of little use to end users.

I agree here, too. I think most people who want to use the library
won't ever run or touch the tests. Heck, I only ever ran the tests
after I started contributing back to the community. Perhaps they
should be spawn off to a matplotlib-tests git submodule that Travis
can use for commit-checking.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Chris B. <chr...@no...>]

On Wed, Oct 3, 2012 at 2:08 PM, Christoph Gohlke <cg...@uc...> wrote:

A bunch of great stuff:

+1 all around

Another use-case is py2exe, py2app, and friends -- at the moment, you
pretty much have to include the whole dang MPL package to get things
to work. Cleaning up some of these dependencies could improve that.

-Chris


> On 10/3/2012 9:20 AM, Michael Droettboom wrote:
>> I invite comments for a new MEP about improving the situation with
>> respect to our bundling of third-party Python dependencies.
>>
>> In particular, I'd love feedback from the various stakeholders -- those
>> producing binary installers and packages for the various platforms.
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP11
>>
>> Mike
>
> Hi,
>
> could dateutil, pytz, and pyparsing be made optional dependencies? I
> just tried, all of my own scripts do work without them being installed
> (one line needed to be removed in axes.py
> https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes.py#L19).
> Only about 10 of matplotlib's examples fail (after some additional
> changes).
>
> Frankly, I would remove/unbundle all 3rd party Python packages from
> matplotlib and declare them as dependencies for pip and easy_install,
> and of course in the documentation.
>
> I think that matplotlib, the library, should not attempt to work around
> Python's distribution/packaging limitations. Please do not use
> post-install or run-time scripts to detect and install missing
> dependencies.
>
> Concerning end user experience, the scipy-stack project seems like a
> better place to address this.
>
> Optionally, for Windows users that won't touch pip or easy_install (like
> me), matplotlib could provide separate downloads of installers for
> dateutil, pytz, pyparsing, and six. They are trivial to create.
>
> It is also easy to create EGGs or MSIs for matplotlib, which are
> occasionally requested.
>
> Also consider a separate package for the matplotlib tests, which would
> include 35 MB of baseline images that are of little use to end users.
>
> Christoph
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Christoph G. <cg...@uc...>]

On 10/3/2012 9:20 AM, Michael Droettboom wrote:
> I invite comments for a new MEP about improving the situation with
> respect to our bundling of third-party Python dependencies.
>
> In particular, I'd love feedback from the various stakeholders -- those
> producing binary installers and packages for the various platforms.
>
> https://github.com/matplotlib/matplotlib/wiki/MEP11
>
> Mike

Hi,

could dateutil, pytz, and pyparsing be made optional dependencies? I 
just tried, all of my own scripts do work without them being installed 
(one line needed to be removed in axes.py 
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes.py#L19). 
Only about 10 of matplotlib's examples fail (after some additional 
changes).

Frankly, I would remove/unbundle all 3rd party Python packages from 
matplotlib and declare them as dependencies for pip and easy_install, 
and of course in the documentation.

I think that matplotlib, the library, should not attempt to work around 
Python's distribution/packaging limitations. Please do not use 
post-install or run-time scripts to detect and install missing 
dependencies.

Concerning end user experience, the scipy-stack project seems like a 
better place to address this.

Optionally, for Windows users that won't touch pip or easy_install (like 
me), matplotlib could provide separate downloads of installers for 
dateutil, pytz, pyparsing, and six. They are trivial to create.

It is also easy to create EGGs or MSIs for matplotlib, which are 
occasionally requested.

Also consider a separate package for the matplotlib tests, which would 
include 35 MB of baseline images that are of little use to end users.

Christoph

[matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue

[Michael D. <md...@st...>]

I invite comments for a new MEP about improving the situation with 
respect to our bundling of third-party Python dependencies.

In particular, I'd love feedback from the various stakeholders -- those 
producing binary installers and packages for the various platforms.

https://github.com/matplotlib/matplotlib/wiki/MEP11

Mike

Re: [matplotlib-devel] deprecate and remove original Navigation toolbar?

[Michael D. <md...@st...>]

+1

On 10/03/2012 04:36 AM, Phil Elson wrote:
> Good question!
>
> It would certainly be a welcome deprecation from my point of view. 
> There is a fair amount of overhead maintaining it if you make any 
> changes to the way backends work (as I have done a couple of times 
> recently).
>
> Depending on feedback here, it is something we could potentially 
> deprecate in 1.2 and then completely remove by 1.3.
>
> Cheers,
>
>
>
>
> On 2 October 2012 20:13, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
>
>     Is there any good reason to retain the original NavigationToolbar code
>     in the backends, and the corresponding "classic" option in
>     rcParams['toolbar']?
>
>     Eric
>
>     ------------------------------------------------------------------------------
>     Don't let slow site performance ruin your business. Deploy New
>     Relic APM
>     Deploy New Relic app performance management and know exactly
>     what is happening inside your Ruby, Python, PHP, Java, and .NET app
>     Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>     http://p.sf.net/sfu/newrelic-dev2dev
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] deprecate and remove original Navigation toolbar?

[Phil E. <pel...@gm...>]

Good question!

It would certainly be a welcome deprecation from my point of view. There is
a fair amount of overhead maintaining it if you make any changes to the way
backends work (as I have done a couple of times recently).

Depending on feedback here, it is something we could potentially deprecate
in 1.2 and then completely remove by 1.3.

Cheers,




On 2 October 2012 20:13, Eric Firing <ef...@ha...> wrote:

> Is there any good reason to retain the original NavigationToolbar code
> in the backends, and the corresponding "classic" option in
> rcParams['toolbar']?
>
> Eric
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] deprecate and remove original Navigation toolbar?

[Eric F. <ef...@ha...>]

Is there any good reason to retain the original NavigationToolbar code 
in the backends, and the corresponding "classic" option in 
rcParams['toolbar']?

Eric

Re: [matplotlib-devel] branch merge strategy

[Damon M. <dam...@gm...>]

On Sun, Sep 30, 2012 at 9:24 PM, Eric Firing <ef...@ha...> wrote:
> On 2012/09/30 7:14 AM, Michael Droettboom wrote:
>> On 09/29/2012 08:07 PM, Eric Firing wrote:
>>> Mike,
>>>
>>> I'm getting confused about branch merge strategy.  Usually, it seems
>>> that it has been to periodically merge the maintenance branch into
>>> master.  Something like this:
>>>
>>> git fetch upstream
>>> git checkout master
>>> git merge --ff-only upstream/master
>>> git merge upstream/v1.2.x
>>> # test, commit changes if necessary
>>> git push upstream master
>>>
>>> Is that correct?
>>>
>>> At present, however, we seem to be developing fairly long separate
>>> threads on the two branches, with duplicate changesets, presumably
>>> from cherry-picking.  Is this intentional?  Do you plan to go back to
>>> the merge strategy?
>>
>> A few things were cherry-picked over to 1.2.x, since the PR was
>> initially set up against master and github doesn't provide a way to
>> change the destination of a PR after creating it.  But that was meant to
>> be the exception...  the "preferred" way hasn't changed.
>>
>>>
>>> I can see that a problem with branch merging is that there are
>>> occasionally changesets in v1.2.x, such as the rc version tagging,
>>> that are not appropriate for master.
>> Tags don't merge across branches because tags are just pointers to
>> particular commit hashes.  When doing a merge, you always get a new
>> commit hash (since the parents are different).  As for updating the
>> version number, however, yes, those changes need to be manually
>> addressed -- though it usually shows up as a merge conflict, so it's
>> obvious that it needs to be done.
>
> Mike,
>
> Thanks. I have performed the merge of v1.2.x into master, and I think
> everything is OK; the changes reflect only the commits that were not
> cherry-picked.  I also reverted what I think was an inadvertent version
> change in master, so now it is back to 1.3.x.
>
> Eric
>
>
>>
>> Mike

I had an idea this morning about how best to resolve this. I think the
developers' lives would be made slightly easier if contributors knew
where to branch from at the outset. I think when most people submit a
pull request (myself included) they automatically branch from master.
This is where the problem lies. If someone is submitting a bug fix
during a release cycle they should almost certainly branch from
v1.2.x, or whatever the current version branch is. This way, if the
pull request gets accept it's trivial to merge it into the correct
place (v1.2.x) and if it's accepted but is not deemed suitable for
v1.2.x it can be rebased onto master. This avoids the, in my opinion,
ugly cherry-picking solution.

Since all of our patches and contributions are taking place on github,
to get this information to contributors I propose updating the
readme.txt file to include this information. It's the first thing
people see when they're on the matplotlib github page so I think it
would make a big difference.

How does that sound?

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] branch merge strategy

[Eric F. <ef...@ha...>]

On 2012/09/30 7:14 AM, Michael Droettboom wrote:
> On 09/29/2012 08:07 PM, Eric Firing wrote:
>> Mike,
>>
>> I'm getting confused about branch merge strategy.  Usually, it seems
>> that it has been to periodically merge the maintenance branch into
>> master.  Something like this:
>>
>> git fetch upstream
>> git checkout master
>> git merge --ff-only upstream/master
>> git merge upstream/v1.2.x
>> # test, commit changes if necessary
>> git push upstream master
>>
>> Is that correct?
>>
>> At present, however, we seem to be developing fairly long separate
>> threads on the two branches, with duplicate changesets, presumably
>> from cherry-picking.  Is this intentional?  Do you plan to go back to
>> the merge strategy?
>
> A few things were cherry-picked over to 1.2.x, since the PR was
> initially set up against master and github doesn't provide a way to
> change the destination of a PR after creating it.  But that was meant to
> be the exception...  the "preferred" way hasn't changed.
>
>>
>> I can see that a problem with branch merging is that there are
>> occasionally changesets in v1.2.x, such as the rc version tagging,
>> that are not appropriate for master.
> Tags don't merge across branches because tags are just pointers to
> particular commit hashes.  When doing a merge, you always get a new
> commit hash (since the parents are different).  As for updating the
> version number, however, yes, those changes need to be manually
> addressed -- though it usually shows up as a merge conflict, so it's
> obvious that it needs to be done.

Mike,

Thanks. I have performed the merge of v1.2.x into master, and I think 
everything is OK; the changes reflect only the commits that were not 
cherry-picked.  I also reverted what I think was an inadvertent version 
change in master, so now it is back to 1.3.x.

Eric


>
> Mike

Re: [matplotlib-devel] branch merge strategy

[Michael D. <md...@st...>]

On 09/29/2012 08:07 PM, Eric Firing wrote:
> Mike,
>
> I'm getting confused about branch merge strategy.  Usually, it seems 
> that it has been to periodically merge the maintenance branch into 
> master.  Something like this:
>
> git fetch upstream
> git checkout master
> git merge --ff-only upstream/master
> git merge upstream/v1.2.x
> # test, commit changes if necessary
> git push upstream master
>
> Is that correct?
>
> At present, however, we seem to be developing fairly long separate 
> threads on the two branches, with duplicate changesets, presumably 
> from cherry-picking.  Is this intentional?  Do you plan to go back to 
> the merge strategy?

A few things were cherry-picked over to 1.2.x, since the PR was 
initially set up against master and github doesn't provide a way to 
change the destination of a PR after creating it.  But that was meant to 
be the exception...  the "preferred" way hasn't changed.

>
> I can see that a problem with branch merging is that there are 
> occasionally changesets in v1.2.x, such as the rc version tagging, 
> that are not appropriate for master.
Tags don't merge across branches because tags are just pointers to 
particular commit hashes.  When doing a merge, you always get a new 
commit hash (since the parents are different).  As for updating the 
version number, however, yes, those changes need to be manually 
addressed -- though it usually shows up as a merge conflict, so it's 
obvious that it needs to be done.

Mike

[matplotlib-devel] branch merge strategy

[Eric F. <ef...@ha...>]

Mike,

I'm getting confused about branch merge strategy.  Usually, it seems 
that it has been to periodically merge the maintenance branch into 
master.  Something like this:

git fetch upstream
git checkout master
git merge --ff-only upstream/master
git merge upstream/v1.2.x
# test, commit changes if necessary
git push upstream master

Is that correct?

At present, however, we seem to be developing fairly long separate 
threads on the two branches, with duplicate changesets, presumably from 
cherry-picking.  Is this intentional?  Do you plan to go back to the 
merge strategy?

I can see that a problem with branch merging is that there are 
occasionally changesets in v1.2.x, such as the rc version tagging, that 
are not appropriate for master.

Eric

[matplotlib-devel] Fwd: Python 3.3 released

[Damon M. <dam...@gm...>]

Forgot to reply all.


---------- Forwarded message ----------
From: Damon McDougall <dam...@gm...>
Date: Sat, Sep 29, 2012 at 8:51 PM
Subject: Re: [matplotlib-devel] Python 3.3 released
To: Benjamin Root <ben...@ou...>


On Sat, Sep 29, 2012 at 6:46 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Saturday, September 29, 2012, Christoph Gohlke wrote:
>>
>> On 9/29/2012 9:48 AM, Damon McDougall wrote:
>> > I've just read that Python 3.3 has been
>> > released<http://python.org/download/releases/3.3.0/> and thought I
>> > would initiate a discussion oriented around adoption and possible
>> > benefits/problems. It appears that, at least for the Mac, there are
>> > issues with certain versions of
>> > ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no
>> > experience with this, so I can't really comment further.
>> >
>>
>> All tests pass with matplotlib-1.2.0rc2.win-amd64-py3.3.
>>
>> Christoph
>>
>
> I wouldnt expect less.  The question is if the TkAgg still works with
> ActiveTcl on the Mac?
>
> Ben Root

I almost never use the GUI stuff in mpl. When I do, it's almost always
the Qt4 backend or the OS X backend. I have never gotten the Tk
backend to work. It always errors out with after popping up a window
(with no plot in it) and fails very gracefully with a TclError, giving
no indication of what Tcl didn't like.

I think Phil is a Tk-er.

--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom


-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] Python 3.3 released

[Benjamin R. <ben...@ou...>]

On Saturday, September 29, 2012, Christoph Gohlke wrote:

> On 9/29/2012 9:48 AM, Damon McDougall wrote:
> > I've just read that Python 3.3 has been
> > released<http://python.org/download/releases/3.3.0/> and thought I
> > would initiate a discussion oriented around adoption and possible
> > benefits/problems. It appears that, at least for the Mac, there are
> > issues with certain versions of
> > ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no
> > experience with this, so I can't really comment further.
> >
>
> All tests pass with matplotlib-1.2.0rc2.win-amd64-py3.3.
>
> Christoph
>
>
I wouldnt expect less.  The question is if the TkAgg still works with
ActiveTcl on the Mac?

Ben Root

Re: [matplotlib-devel] Python 3.3 released

[Christoph G. <cg...@uc...>]

On 9/29/2012 9:48 AM, Damon McDougall wrote:
> I've just read that Python 3.3 has been
> released<http://python.org/download/releases/3.3.0/> and thought I
> would initiate a discussion oriented around adoption and possible
> benefits/problems. It appears that, at least for the Mac, there are
> issues with certain versions of
> ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no
> experience with this, so I can't really comment further.
>

All tests pass with matplotlib-1.2.0rc2.win-amd64-py3.3.

Christoph

[matplotlib-devel] Python 3.3 released

[Damon M. <dam...@gm...>]

I've just read that Python 3.3 has been
released<http://python.org/download/releases/3.3.0/> and thought I
would initiate a discussion oriented around adoption and possible
benefits/problems. It appears that, at least for the Mac, there are
issues with certain versions of
ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no
experience with this, so I can't really comment further.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] quick bug fix

[Eric F. <ef...@ha...>]

On 2012/09/27 7:13 PM, Alexander Heger wrote:
> I am not sure what I need to do to get any bug fixes included into mpl.

The most efficient way is with a pull request.  And perhaps a little 
patience combined with persistence.

> All previous attempts failed.
> Is it a community effort?

Yes, but that doesn't mean that every suggested change will be accepted, 
or even reviewed right away.

>
> I now attached a patch.
Thank you.

I will comment on github.
https://github.com/matplotlib/matplotlib/issues/1317

Eric

>
> -Alexander
>
> On 25/09/12 23:58, Alexander Heger wrote:
>> Could you please change in the current branch in
>>
>> axes.py, line 7585
>> (Axes.pcolorfast)
>>
>>
>>           nr, nc = C.shape
>> to
>>           nr, nc = C.shape[:2]
>>
>>
>> this way one can pass [nx,ny,3] or [nx,ny,4] arrays to the routine - for
>> which the PcolorImage it calls is made (style == "pcolorimage")
>>
>> -Alexander

Re: [matplotlib-devel] quick bug fix

[Alexander H. <mat...@2s...>]

I am not sure what I need to do to get any bug fixes included into mpl.
All previous attempts failed.
Is it a community effort?

I now attached a patch.

-Alexander

On 25/09/12 23:58, Alexander Heger wrote:
> Could you please change in the current branch in
>
> axes.py, line 7585
> (Axes.pcolorfast)
>
>
>           nr, nc = C.shape
> to
>           nr, nc = C.shape[:2]
>
>
> this way one can pass [nx,ny,3] or [nx,ny,4] arrays to the routine - for
> which the PcolorImage it calls is made (style == "pcolorimage")
>
> -Alexander
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Todd <tod...@gm...>]

On Thu, Sep 27, 2012 at 1:44 PM, Todd <tod...@gm...> wrote:
> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
> <dam...@gm...> wrote:
>> Hi Todd,
>>
>> Firstly, thanks for taking the time to crystallise your thoughts in
>> words first. This is one of my bad habits; I tend to rush into things.
>>
>> I have some feedback for you, hopefully we can all work together to
>> get this right. It's difficult when something new gets implemented and
>> someone expects it to do something and the only way to resolve it is
>> to break the calling API.
>
> Where is API broken?
>
>> Anyway, I hope you'll find my comments
>> helpful at the least. I also encourage others to weigh in with
>> opinions and ideas.
>
> Okay, I will discuss the rationale.  I will snip out anything you
> agree on for brevity.
>
>>> Assuming we go with the name, here is my proposed call signature:
>>>
>>> EventRaster(x, offset=0, height=1, **kargs)
>>
>> CamelCase is discouraged for method names. Perhaps 'eventraster'?
>
> Fair enough.
>
>> Also, we could also let **kwargs swallow the 'offset' and 'height'
>> keyword arguments. Then the user isn't constrained by which order to
>> put them in. The downside of this approach is that introspection is
>> more difficult.
>
> I don't understand the advantage of this approach.  If you use keyword
> arguments, then the order doesn't matter.  So with the approach above
> you can use keyword arguments, in which case you can use whatever
> order they want, or you can use positional arguments.  On the other
> hand putting it in **kwargs, we lose the ability to use positional
> arguments.  So we lose nothing by allowing both positional and keyword
> arguments.  It is also easier to implement.
>
>>> offset determines the positions of the rows.  By default, the first
>>> row is placed with the line center y=0, and subsequent rows are placed
>>> with the line centers at increasing 1-unit increments.  If offset is
>>> defined and is a scalar, the first row is placed at the offset, and
>>> subsequent rows are placed at increasing 1-unit increments.  If offset
>>> is an array, it must be a 1D array of the same length as the second
>>> dimension of x.  In this case each element in offset determines the
>>> center of the corresponding row in the plot.
>>
>> How about letting offset be either: a) a scalar, determining the
>> offset of all rows equally; or b) an array, determining the offset of
>> each row individually.
>
> Because people are almost never going to want to have all the lines
> stacked right on top of each other.  The plot would be indecipherable
> that way.  The defaults are chosen to handle the most common use-cases
> most easily.
>
>> In fact, why plot each row at integer y
>> coordinates? Could we allow for an optional y-coordinate array, each
>> element of which would be the y-coordinate at which to plot a row of
>> lines. Then you wouldn't need offset.
>
> That is exactly what offset does if you pass an array.
>
>>> If this is going to be used to implement rug plots, it would need some
>>> way to handle columns of horizontal lines in addition to rows of
>>> vertical lines.  I see two ways to implement this.  First is to have
>>> to plot types, perhaps HEventRaster and VEventRaster.  The first would
>>> be as described above, while the second would be similar but
>>> everything rotated 90 degrees.  Another possibility is to change the
>>> call signature to this:
>>>
>>> EventRaster(x, y=None, offset=0, height=1, **kargs)
>>
>> I think accepting an 'orientation' kwarg, which can take either
>> 'horizontal' or 'vertical', determining the orientation of the lines
>> and reversing the roles of the x and y arrays.
>
> That would work as well.  Probably cleaner that way
>
>>> The function will return a list of a new collection type I am
>>> tentatively calling EventCollection.  My thinking would be this would
>>> be a subclass of a new collection type called GenericLineCollection,
>>> which the current LineCollection would also subclass.  They would
>>> share things like the color handling and segment handling, however the
>>> segment handling will be a "private" method that LineCollection will
>>> have a public wrapper for.  On the other hand methods to set or add
>>> segments will remain private in EventCollection, although there will
>>> be a method to return the segments if an artist really wants to
>>> manipulate individual segments.
>>
>> Why can't we just use LineCollection? I don't see a good reason to
>> create a new collection class here; the plot is simple.
>
> Explained below.
>
>>> The reason for doing it this way is that manipulating individual rows
>>> of events should be very common, such as changing their position,
>>> color, marker, width, and so on.  On the other hand manipulating lines
>>> individually should not be as common, although still supported.
>>
>> Fair enough, then maybe a better idea is to create your own
>> EventRaster class (note camel case) to hold all the relevant data in
>> arrays. Then make a 'construct_raster' method could return a
>> LineCollection. Then again, weren't you passing extra kwargs to
>> 'plot'? This approach would surely use ax.add_lines or
>> ax.add_linecollection something (I can't remember what it's called).
>
> The whole point of creating a new collection type is that artists will
> be able to manipulate individual sets of events.
>
> For example, with an ordinary LineCollection it will be extremely
> difficult to change the marker type, since doing so will change the
> marker for all 3 points on each segment rather than just the middle
> point.  So if someone makes the plot, than wants to set rows to have
> different marker types instead of being lines, they can do that if we
> use a new collection class.  But if we use LineCollection this becomes
> much more difficult.
>
> Similarly, with a LineCollection the lines lose their status as
> objects with a single distinct position.  They become objects with 3
> 2D coordinates.  So if someone wants to add more events to the end,
> they need to take care of handling the x and y coordinates, making
> sure the x coordinates are the same and taking the y coordinates from
> one of the existing lines. Similarly changing the height or vertical
> position of all the objects is complicated, having to manually
> calculate and modify the y coordinates of each point in each segment.
>
> Again, the idea here is to make the most common use-cases as easy as
> possible.  LineCollection objects aren't really suited to the sort of
> artistic changes that are typical with this sort of plot.
>
> In fact I would say that having a separate collection class is central
> to this idea.  If users aren't able to manipulate the set of events as
> such after they create the plot, then there really isn't any advantage
> over just using a vlines plot. Calculating the ymin and ymax is one
> line of code each, it is the artistic changes that save many lines of
> code and a lot of complexity.

I would also like to add that the new collection object would be
useful outside of this plot type.

For example if someone wanted to create a rug plot as Nathaniel
described, and they want those along the same axes as the main plot,
then they would most likely not be be using the plot function, but
rather creating two individual collection objects in an existing
figure.

I can imagine other cases besides a strict rug plot where adding such
a collection object could be useful.

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Todd <tod...@gm...>]

On Thu, Sep 27, 2012 at 2:17 PM, Damon McDougall
<dam...@gm...> wrote:
> On Thu, Sep 27, 2012 at 12:44 PM, Todd <tod...@gm...> wrote:
>> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
>> <dam...@gm...> wrote:
>>> Hi Todd,
>>>
>>> Firstly, thanks for taking the time to crystallise your thoughts in
>>> words first. This is one of my bad habits; I tend to rush into things.
>>>
>>> I have some feedback for you, hopefully we can all work together to
>>> get this right. It's difficult when something new gets implemented and
>>> someone expects it to do something and the only way to resolve it is
>>> to break the calling API.
>>
>> Where is API broken?
>
> Nowhere. I wasn't implying you were breaking something. My point was
> that it's easy to add functionality but hard to remove it, therefore
> it's important to get it right from the outset. I'm sorry for the
> misunderstanding; I wasn't clear.

No problem.  I put a lot of other comments inline in my reply to your
email, but your mail reader might have cut them off.

-Todd

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Damon M. <dam...@gm...>]

On Thu, Sep 27, 2012 at 12:44 PM, Todd <tod...@gm...> wrote:
> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
> <dam...@gm...> wrote:
>> Hi Todd,
>>
>> Firstly, thanks for taking the time to crystallise your thoughts in
>> words first. This is one of my bad habits; I tend to rush into things.
>>
>> I have some feedback for you, hopefully we can all work together to
>> get this right. It's difficult when something new gets implemented and
>> someone expects it to do something and the only way to resolve it is
>> to break the calling API.
>
> Where is API broken?

Nowhere. I wasn't implying you were breaking something. My point was
that it's easy to add functionality but hard to remove it, therefore
it's important to get it right from the outset. I'm sorry for the
misunderstanding; I wasn't clear.

>
>> Anyway, I hope you'll find my comments
>> helpful at the least. I also encourage others to weigh in with
>> opinions and ideas.
>
> Okay, I will discuss the rationale.  I will snip out anything you
> agree on for brevity.
>
>>> Assuming we go with the name, here is my proposed call signature:
>>>
>>> EventRaster(x, offset=0, height=1, **kargs)
>>
>> CamelCase is discouraged for method names. Perhaps 'eventraster'?
>
> Fair enough.
>
>> Also, we could also let **kwargs swallow the 'offset' and 'height'
>> keyword arguments. Then the user isn't constrained by which order to
>> put them in. The downside of this approach is that introspection is
>> more difficult.
>
> I don't understand the advantage of this approach.  If you use keyword
> arguments, then the order doesn't matter.  So with the approach above
> you can use keyword arguments, in which case you can use whatever
> order they want, or you can use positional arguments.  On the other
> hand putting it in **kwargs, we lose the ability to use positional
> arguments.  So we lose nothing by allowing both positional and keyword
> arguments.  It is also easier to implement.
>
>>> offset determines the positions of the rows.  By default, the first
>>> row is placed with the line center y=0, and subsequent rows are placed
>>> with the line centers at increasing 1-unit increments.  If offset is
>>> defined and is a scalar, the first row is placed at the offset, and
>>> subsequent rows are placed at increasing 1-unit increments.  If offset
>>> is an array, it must be a 1D array of the same length as the second
>>> dimension of x.  In this case each element in offset determines the
>>> center of the corresponding row in the plot.
>>
>> How about letting offset be either: a) a scalar, determining the
>> offset of all rows equally; or b) an array, determining the offset of
>> each row individually.
>
> Because people are almost never going to want to have all the lines
> stacked right on top of each other.  The plot would be indecipherable
> that way.  The defaults are chosen to handle the most common use-cases
> most easily.
>
>> In fact, why plot each row at integer y
>> coordinates? Could we allow for an optional y-coordinate array, each
>> element of which would be the y-coordinate at which to plot a row of
>> lines. Then you wouldn't need offset.
>
> That is exactly what offset does if you pass an array.
>
>>> If this is going to be used to implement rug plots, it would need some
>>> way to handle columns of horizontal lines in addition to rows of
>>> vertical lines.  I see two ways to implement this.  First is to have
>>> to plot types, perhaps HEventRaster and VEventRaster.  The first would
>>> be as described above, while the second would be similar but
>>> everything rotated 90 degrees.  Another possibility is to change the
>>> call signature to this:
>>>
>>> EventRaster(x, y=None, offset=0, height=1, **kargs)
>>
>> I think accepting an 'orientation' kwarg, which can take either
>> 'horizontal' or 'vertical', determining the orientation of the lines
>> and reversing the roles of the x and y arrays.
>
> That would work as well.  Probably cleaner that way
>
>>> The function will return a list of a new collection type I am
>>> tentatively calling EventCollection.  My thinking would be this would
>>> be a subclass of a new collection type called GenericLineCollection,
>>> which the current LineCollection would also subclass.  They would
>>> share things like the color handling and segment handling, however the
>>> segment handling will be a "private" method that LineCollection will
>>> have a public wrapper for.  On the other hand methods to set or add
>>> segments will remain private in EventCollection, although there will
>>> be a method to return the segments if an artist really wants to
>>> manipulate individual segments.
>>
>> Why can't we just use LineCollection? I don't see a good reason to
>> create a new collection class here; the plot is simple.
>
> Explained below.
>
>>> The reason for doing it this way is that manipulating individual rows
>>> of events should be very common, such as changing their position,
>>> color, marker, width, and so on.  On the other hand manipulating lines
>>> individually should not be as common, although still supported.
>>
>> Fair enough, then maybe a better idea is to create your own
>> EventRaster class (note camel case) to hold all the relevant data in
>> arrays. Then make a 'construct_raster' method could return a
>> LineCollection. Then again, weren't you passing extra kwargs to
>> 'plot'? This approach would surely use ax.add_lines or
>> ax.add_linecollection something (I can't remember what it's called).
>
> The whole point of creating a new collection type is that artists will
> be able to manipulate individual sets of events.
>
> For example, with an ordinary LineCollection it will be extremely
> difficult to change the marker type, since doing so will change the
> marker for all 3 points on each segment rather than just the middle
> point.  So if someone makes the plot, than wants to set rows to have
> different marker types instead of being lines, they can do that if we
> use a new collection class.  But if we use LineCollection this becomes
> much more difficult.
>
> Similarly, with a LineCollection the lines lose their status as
> objects with a single distinct position.  They become objects with 3
> 2D coordinates.  So if someone wants to add more events to the end,
> they need to take care of handling the x and y coordinates, making
> sure the x coordinates are the same and taking the y coordinates from
> one of the existing lines. Similarly changing the height or vertical
> position of all the objects is complicated, having to manually
> calculate and modify the y coordinates of each point in each segment.
>
> Again, the idea here is to make the most common use-cases as easy as
> possible.  LineCollection objects aren't really suited to the sort of
> artistic changes that are typical with this sort of plot.
>
> In fact I would say that having a separate collection class is central
> to this idea.  If users aren't able to manipulate the set of events as
> such after they create the plot, then there really isn't any advantage
> over just using a vlines plot. Calculating the ymin and ymax is one
> line of code each, it is the artistic changes that save many lines of
> code and a lot of complexity.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom