matplotlib-devel Mailing List for matplotlib (Page 2)

On Sun, Dec 16, 2012 at 2:44 PM, Eric Firing <ef...@ha...> wrote:
> On 2012年12月16日 9:21 AM, Damon McDougall wrote:
>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
>> <jas...@cr...> wrote:
>>> On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>>>> sourceforge's horror of an interface.
>>>
>>> I'll second that. Every time I go to Sourceforge, I have to figure out
>>> how in the world to download what I want (and I have to figure out which
>>> things *not* to click on too).
>>
>> Ok sounds like there is a reasonable amount of resistance towards Sourceforge.
>>
>> Eric, when you suggest that NumFocus could 'provide hosting directly',
>> do you mean they would have the physical hardware to host the files,
>> or are you suggesting they provide the finances to seek hosting
>> elsewhere?
>
> I was thinking that perhaps NumFocus would be running a server that
> could provide the hosting. Funding for an external service is also
> possible, though, and might make more sense.
>
>>
>> In the GitHub blog post, they suggest using S3. We could try that.
>> It's fairly inexpensive and the first year is free (within monthly
>> bandwidth limits). We could try it for a year and see how that pans
>> out? I'm not entirely sure how the Amazon stuff works but I've heard
>> good things about it.
>>
>
> The github page https://github.com/matplotlib/matplotlib/downloads shows
> 44,000 downloads for the 1.2 tarball, so I don't think the 20,000
> downloads per month limit of the free tier would work.
Note: that's 44,000 downloads for a gzipped bundle of the *source*,
which can still be downloaded via the "Tags" tab
(https://github.com/matplotlib/matplotlib/tags). Any time one of us
creates a tag, GitHub automagically tar/gzips it and makes it
downloadable. As far as I am aware, this is separate to the
"Downloads" section, which is for arbitrary files of any type, not
just source tarballs.
That said, not taking into account the downloads of the tarball, we're
still pretty close to the 20,000 mark.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On 2012年12月16日 9:21 AM, Damon McDougall wrote:
> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
> <jas...@cr...> wrote:
>> On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>>> sourceforge's horror of an interface.
>>
>> I'll second that. Every time I go to Sourceforge, I have to figure out
>> how in the world to download what I want (and I have to figure out which
>> things *not* to click on too).
>
> Ok sounds like there is a reasonable amount of resistance towards Sourceforge.
>
> Eric, when you suggest that NumFocus could 'provide hosting directly',
> do you mean they would have the physical hardware to host the files,
> or are you suggesting they provide the finances to seek hosting
> elsewhere?
I was thinking that perhaps NumFocus would be running a server that 
could provide the hosting. Funding for an external service is also 
possible, though, and might make more sense.
>
> In the GitHub blog post, they suggest using S3. We could try that.
> It's fairly inexpensive and the first year is free (within monthly
> bandwidth limits). We could try it for a year and see how that pans
> out? I'm not entirely sure how the Amazon stuff works but I've heard
> good things about it.
>
The github page https://github.com/matplotlib/matplotlib/downloads shows 
44,000 downloads for the 1.2 tarball, so I don't think the 20,000 
downloads per month limit of the free tier would work.
Eric

On Sun, Dec 16, 2012 at 1:38 PM, Todd <tod...@gm...> wrote:
> On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall <dam...@gm...>
> wrote:
>>
>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
>> <jas...@cr...> wrote:
>> > On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>> >> sourceforge's horror of an interface.
>> >
>> > I'll second that. Every time I go to Sourceforge, I have to figure out
>> > how in the world to download what I want (and I have to figure out which
>> > things *not* to click on too).
>>
>> Ok sounds like there is a reasonable amount of resistance towards
>> Sourceforge.
>>
>> Eric, when you suggest that NumFocus could 'provide hosting directly',
>> do you mean they would have the physical hardware to host the files,
>> or are you suggesting they provide the finances to seek hosting
>> elsewhere?
>>
>> In the GitHub blog post, they suggest using S3. We could try that.
>> It's fairly inexpensive and the first year is free (within monthly
>> bandwidth limits). We could try it for a year and see how that pans
>> out? I'm not entirely sure how the Amazon stuff works but I've heard
>> good things about it.
>>
>>
> Are you sure the monthly bandwidth limits are sufficient?
>
> Also, have you talked to the pypi people about making exceptions for really
> popular projects? If critical packages like numpy, scipy, and matplotlib
> cannot use pypi, that seems like a major failing of the system.
Here's the pricing: http://aws.amazon.com/s3/#pricing. The free tier
programme limits are on there too. Unfortunately, I do not have the
knowledge to be able to say whether we would hit that or not.
Matt, have you had experienced comitting binaries to the gh-pages
branch? Are there size limits?
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall
<dam...@gm...>wrote:
> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
> <jas...@cr...> wrote:
> > On 12/14/12 10:55 AM, Nathaniel Smith wrote:
> >> sourceforge's horror of an interface.
> >
> > I'll second that. Every time I go to Sourceforge, I have to figure out
> > how in the world to download what I want (and I have to figure out which
> > things *not* to click on too).
>
> Ok sounds like there is a reasonable amount of resistance towards
> Sourceforge.
>
> Eric, when you suggest that NumFocus could 'provide hosting directly',
> do you mean they would have the physical hardware to host the files,
> or are you suggesting they provide the finances to seek hosting
> elsewhere?
>
> In the GitHub blog post, they suggest using S3. We could try that.
> It's fairly inexpensive and the first year is free (within monthly
> bandwidth limits). We could try it for a year and see how that pans
> out? I'm not entirely sure how the Amazon stuff works but I've heard
> good things about it.
>
>
> Are you sure the monthly bandwidth limits are sufficient?
Also, have you talked to the pypi people about making exceptions for really
popular projects? If critical packages like numpy, scipy, and matplotlib
cannot use pypi, that seems like a major failing of the system.

On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
<jas...@cr...> wrote:
> On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>> sourceforge's horror of an interface.
>
> I'll second that. Every time I go to Sourceforge, I have to figure out
> how in the world to download what I want (and I have to figure out which
> things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On 12/14/12 10:55 AM, Nathaniel Smith wrote:
> sourceforge's horror of an interface.
I'll second that. Every time I go to Sourceforge, I have to figure out 
how in the world to download what I want (and I have to figure out which 
things *not* to click on too).
Thanks,
Jason

Hi,
> Github has removed the ability to host binaries. They've removed this
> feature without any apparent notification except on their blog saying
> "it's gone today". And the suggested alternative is to use paid services.
>
> https://github.com/blog/1302-goodbye-uploads
>
> I had planned to complete our set of 1.2.0 binaries with a Python 3.2
> from Russell Owen in the near future. So much for that.
>
> Any thoughts? Do we go back to Sourceforge for our download hosting?
> Is anyone familiar with any other services? Do we try to piggy-back on
> what other scipy projects are doing?
Why not use a gh-pages branch to host both docs and binary files from github?
--Matt Newville

On 2012年12月14日 6:58 AM, Michael Droettboom wrote:
> Github has removed the ability to host binaries. They've removed this
> feature without any apparent notification except on their blog saying
> "it's gone today". And the suggested alternative is to use paid services.
>
> https://github.com/blog/1302-goodbye-uploads
>
> I had planned to complete our set of 1.2.0 binaries with a Python 3.2
> from Russell Owen in the near future. So much for that.
>
> Any thoughts? Do we go back to Sourceforge for our download hosting?
> Is anyone familiar with any other services? Do we try to piggy-back on
> what other scipy projects are doing?
>
> Mike
Mike,
It doesn't sound like any of the standard alternatives is very suitable. 
 Maybe Numfocus could provide the hosting directly?
Eric

On Sat, Dec 15, 2012 at 5:47 PM, Thomas Kluyver <th...@kl...> wrote:
> On 15 December 2012 23:38, Damon McDougall <dam...@gm...>
> wrote:
>>
>> Maybe the best thing is to host the binaries on Sourceforge.
>
>
> Having recently tried to do it, Sourceforge tries really hard to avoid
> giving you a direct link that can repeatably be used to download a file
> automatically, i.e. without a browser. In the case I was after it for, I
> ended up downloading the file (a PyWin32 binary) with a browser, and storing
> it on the CI server that I wanted to install it.
Thanks for that information, Thomas. I conclude hosting the binaries
on Sourceforge and just linking to them from the mpl website is not
feasible. Unless, of course, there is resistance to the idea of
linking to them from the website.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On 15 December 2012 23:38, Damon McDougall <dam...@gm...>wrote:
> Maybe the best thing is to host the binaries on Sourceforge.
Having recently tried to do it, Sourceforge tries really hard to avoid
giving you a direct link that can repeatably be used to download a file
automatically, i.e. without a browser. In the case I was after it for, I
ended up downloading the file (a PyWin32 binary) with a browser, and
storing it on the CI server that I wanted to install it.
Thomas

I'm very pleased to announce the first release candidate for Oscopy
v0.71. For those just tuning in, Oscopy is a plotting program based on
IPython for viewing and post-processing results of electrical
simulations (more details on oscopy website [1]). Documentation can be
found here [2].
Main user-visible change of this version:
* Support for new input data format: spice2, spice3, touchstone, ...
* New zooming functions: mouse-wheel support, x10 mode, span
* Figure windows reworked: new operation bar, scrollbars for panning
* Command line options restored: batch mode, interactive, quiet
* Duplicate Signals are renamed on file reading
* Update of User Manual
* Now installation is needed to run oscopy.
Main developer-visible changes:
* Separation between back-end (oscopy) and front-end (ioscopy)
And of course a lot of bug fixes.
Significant improvements were performed on the look and feel of the
graphical interface and input file formats. Before releasing the v0.71 I
eagerly need a feedback on those changes to make sure I'm going in the
right direction, this is why I announce a RC here.
I would really appreciate if you could give a try to this version: check
out this RC, verify it installs correctly, and test it. I kindly ask you
to report any bugs on oscopy-dev mailing list
(mailto:osc...@os...) in CC of this message.
The source code is hosted at repo.or.cz: http://repo.or.cz/w/oscopy.git
My apologies for the multiples posts.
Arnaud.
[1] http://oscopy.org
[2] http://oscopy.org/wiki/_media/oscopy/ioscopy-manual-071.pdf

On Sat, Dec 15, 2012 at 5:24 PM, Michael Droettboom <md...@st...> wrote:
> On 12/14/2012 02:25 PM, Todd wrote:
>
>
> On Dec 14, 2012 5:59 PM, "Michael Droettboom" <md...@st...> wrote:
>>
>> Github has removed the ability to host binaries. They've removed this
>> feature without any apparent notification except on their blog saying "it's
>> gone today". And the suggested alternative is to use paid services.
>>
>> https://github.com/blog/1302-goodbye-uploads
>>
>> I had planned to complete our set of 1.2.0 binaries with a Python 3.2 from
>> Russell Owen in the near future. So much for that.
>>
>> Any thoughts? Do we go back to Sourceforge for our download hosting? Is
>> anyone familiar with any other services? Do we try to piggy-back on what
>> other scipy projects are doing?
>>
>> Mike
>>
>
> Is there a reason pypi is not usable?
>
> PyPI doesn't support large enough files. (I'm not sure what the limit is,
> but I've hit it every time). We have always hosted our files elsewhere and
> then just had PyPI point to them.
>
> Mike
This seems like a pretty big minus, especially considering the work
you and others have put in migrating everything over from Sourceforge.
Do you think it would be worth contacting the GitHub folks about this?
I'm not sure what I'm trying to achieve. I guess I'd like them to
realise that GitHub Downloads were a really useful feature and their
reasons for removing it without deprecation of the GitHub Uploads
process has made the distribution of matplotlib more confusing for our
users.
Perhaps it's better just to move on...
I've been (un?)fortunate enough to never have to use Sourceforge's
interface. If it's the case it's not intuitive then I like Nathaniel's
idea of hosting the binaries on Google Code. The downside of this, of
course, is that matplotlib is then spread across three different
services: Sourceforge for the mailing list; GitHub for the source and
development; and Google Code for the binaries.
Maybe the best thing is to host the binaries on Sourceforge.
To be honest, I'm not sure that the service that hosts the binaries
matters all that much. We could put links to the binaries on the
webpage and then it's completely transparent to the user.
Sorry for the stream of conscience.
Best wishes,
Damon
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On 12/14/2012 02:25 PM, Todd wrote:
>
>
> On Dec 14, 2012 5:59 PM, "Michael Droettboom" <md...@st... 
> <mailto:md...@st...>> wrote:
> >
> > Github has removed the ability to host binaries. They've removed 
> this feature without any apparent notification except on their blog 
> saying "it's gone today". And the suggested alternative is to use 
> paid services.
> >
> > https://github.com/blog/1302-goodbye-uploads
> >
> > I had planned to complete our set of 1.2.0 binaries with a Python 
> 3.2 from Russell Owen in the near future. So much for that.
> >
> > Any thoughts? Do we go back to Sourceforge for our download 
> hosting? Is anyone familiar with any other services? Do we try to 
> piggy-back on what other scipy projects are doing?
> >
> > Mike
> >
>
> Is there a reason pypi is not usable?
>
PyPI doesn't support large enough files. (I'm not sure what the limit 
is, but I've hit it every time). We have always hosted our files 
elsewhere and then just had PyPI point to them.
Mike

On Dec 14, 2012 5:59 PM, "Michael Droettboom" <md...@st...> wrote:
>
> Github has removed the ability to host binaries. They've removed this
feature without any apparent notification except on their blog saying "it's
gone today". And the suggested alternative is to use paid services.
>
> https://github.com/blog/1302-goodbye-uploads
>
> I had planned to complete our set of 1.2.0 binaries with a Python 3.2
from Russell Owen in the near future. So much for that.
>
> Any thoughts? Do we go back to Sourceforge for our download hosting? Is
anyone familiar with any other services? Do we try to piggy-back on what
other scipy projects are doing?
>
> Mike
>
Is there a reason pypi is not usable?
>
------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 14 Dec 2012 16:59, "Michael Droettboom" <md...@st...> wrote:
>
> Github has removed the ability to host binaries. They've removed this
feature without any apparent notification except on their blog saying "it's
gone today". And the suggested alternative is to use paid services.
>
> https://github.com/blog/1302-goodbye-uploads
>
> I had planned to complete our set of 1.2.0 binaries with a Python 3.2
from Russell Owen in the near future. So much for that.
>
> Any thoughts? Do we go back to Sourceforge for our download hosting? Is
anyone familiar with any other services? Do we try to piggy-back on what
other scipy projects are doing?
I don't think other scipy projects are doing anything special here; numpy
and scipy never stopped using sourceforge. If you wanted to lead the way on
setting up some simple download hosting on S3 or whatever for scipy
projects then you could probably get numfocus to pay the hosting costs.
Alternatively I'd consider Google code before going back to sourceforge -
IME the service is similar overall but without sourceforge's horror of an
interface.
-n

> Any thoughts? Do we go back to Sourceforge for our download hosting? Is
> anyone familiar with any other services? Do we try to piggy-back on what
> other scipy projects are doing?
Scikit-learn uses sourceforge.
Scikits-image doesn't provide download links on the website (except
for windows binary, hosted on someone's webpage), but uses pipy's
hosting services.
I think sourceforge is OK.
Cheers,
N
>
> Mike
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Github has removed the ability to host binaries. They've removed this 
feature without any apparent notification except on their blog saying 
"it's gone today". And the suggested alternative is to use paid services.
https://github.com/blog/1302-goodbye-uploads
I had planned to complete our set of 1.2.0 binaries with a Python 3.2 
from Russell Owen in the near future. So much for that.
Any thoughts? Do we go back to Sourceforge for our download hosting? 
Is anyone familiar with any other services? Do we try to piggy-back on 
what other scipy projects are doing?
Mike

Hurray! https://github.com/blog/1347-issue-attachments

Paul Hobson writes:
 > On Wed, Dec 12, 2012 at 5:59 AM, Michael Droettboom <md...@st...> wrote:
 > 
 > http://matplotlib.org/examples/api/clippath_demo.html
 > 
 > It's perfectly reasonable code, but seems strange that it's
 > clipped off to the corner which I think makes it less useful as
 > an example.
 > 
 > If I understand correctly, you're proposing that that such an
 > example would be deleted after a more practical example was
 > available to replace it?
 > 
 > While I'm 100% in favor of "cleaning out the closet", I used this exact
 > example two days ago to clip a depressed groundwater surface to a landfill
 > boundary :)
There is one small issue with the example: If one is using imshow on
random pixel data, there is not reason to use bilinear interpolation
(which is what imshow defaults to). "nearest" is the only reasonable
choice. 
I know this sounds pedantic, but it irks me as a numerical analyst...
--Marcel

On 12/12/2012 01:17 PM, Paul Hobson wrote:
>
> On Wed, Dec 12, 2012 at 5:59 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>
> http://matplotlib.org/examples/api/clippath_demo.html
>
> It's perfectly reasonable code, but seems strange that it's
> clipped off to the corner which I think makes it less useful as an
> example.
>
>
> If I understand correctly, you're proposing that that such an example 
> would be deleted after a more practical example was available to 
> replace it?
>
> While I'm 100% in favor of "cleaning out the closet", I used this 
> exact example two days ago to clip a depressed groundwater surface to 
> a landfill boundary :)
I'm suggesting updating it to be even more useful, and to make the 
thumbnail image more illustrative of the technique that it demonstrates.
Mike

On Wed, Dec 12, 2012 at 5:59 AM, Michael Droettboom <md...@st...> wrote:
>
> http://matplotlib.org/examples/api/clippath_demo.html
>
> It's perfectly reasonable code, but seems strange that it's clipped off to
> the corner which I think makes it less useful as an example.
>
>
If I understand correctly, you're proposing that that such an example would
be deleted after a more practical example was available to replace it?
While I'm 100% in favor of "cleaning out the closet", I used this exact
example two days ago to clip a depressed groundwater surface to a landfill
boundary :)

On 12/11/2012 07:16 PM, Thomas Kluyver wrote:
> On 11 December 2012 23:07, Tony Yu <ts...@gm... 
> <mailto:ts...@gm...>> wrote:
>
> You suggest keeping the old examples around in some dark
> corner. Is there some advantage you envision for doing this?
> I'd just as soon remove them. Note that the documentation on
> the website is now versioned, so the examples that shipped
> with 1.2.0 will remain live and unchanged indefinitely. If a
> user wants the older gallery it should just be there under
> matplotlib.org/1.2 <http://matplotlib.org/1.2>.
>
>
> I noted that old examples could either be kept in a dark corner,
> or deleted. I'm actually strongly in favor of deleting, especially
> since the website is versioned (nice---I didn't know this). I was
> afraid some people would be resistant to deleting, but I'm happy
> to hear that you prefer it. I'll make this preference clearer in
> the MEP.
>
>
> I haven't had time to consider all the details of this proposal, but 
> I'd like to advise against overzealous deletion. For those of us less 
> familiar with matplotlib's API, a pretty standard approach is to scan 
> through the examples gallery for the plot that looks most like the one 
> we want, copy the code and tweak it into what we need. So a big 
> gallery is very useful.
I don't think Tony was suggesting deleting many of the examples -- only 
deleting any old stuff after reorganization of what we already have.
I was suggesting deleting a few examples that really aren't useful to 
end users, and are really just unit tests (predating our unit test 
framework). The sort of thing I was suggesting deleting are:
http://matplotlib.org/examples/api/donut_demo.html
which is really a unit test. It's highly unlikely the user would create 
those shapes directly, and if they were we have the dolphin demo which 
makes more sense from an end user perspective.
There are also examples that are sort of developer oriented that should 
probably just be updated to be less so, for example:
http://matplotlib.org/examples/api/clippath_demo.html
It's perfectly reasonable code, but seems strange that it's clipped off 
to the corner which I think makes it less useful as an example.
>
> Of course, that doesn't mean it should grow ad infinitum, and I'm sure 
> you'll use good judgement on this. I just wanted to check you were 
> aware of this use case.
>
Absolutely. I think that's a major use case for the gallery.
Cheers,
Mike
> Best wishes,
> Thomas

Tony Yu writes:
 > MEP 12 outlines the reorganization of the example gallery and
 > subsequent clean up of the examples:
 > 
 > https://github.com/matplotlib/matplotlib/wiki/MEP12
Dear all,
thanks for this initiative. As a user who has done a fair amount of
tweaking for publication-quality graphics, but who cannot claim to
have a deep understanding of the overall architecture of matplotlib,
the gallery has long been on my radar as something in need of
improvement. I believe that the MEP goes in the right direction, but
I could see some more radical changes as well.
Independent of ordering by topic, I see three categories of examples:
1. API documentation/illustration of basic functionality
2. HOWTO: task driven examples (how to create a certain type of graph,
 how to perform a certain useful tweak)
3. Showcases (complete projects of typically higher complexity than
 the above, code could also contain substantial sections which are
 related to data-generation, preparation, or simulation)
For the category 1 examples, the examples are really part of the API
documentation and the gallery is just a thumbnail view which makes it
easier to use eye-ball navigation through the matplotlib
documentation. I believe this is already how it works today, but it's
not really clear from the structure of the gallery. The category 1
examples should be clearly recognizable as views into a more
comprehensive document and also given some structure (by stating
function/methods to whose documentation they are attached, for
example, and/or by the categories outlined in the MEP).
For the category 2 examples, one needs to think in terms of the
workflow. This will likely need to grow as new tasks and problems
come to peoples attention, so just a very superficial selection of
topics which have come across in my own work:
- How do I change the text size of the legend (or of labels, etc.)
- How do I make matplotlib use only one marker symbol in the legend
 (because each symbols refers not to a graph of something, but to a
 unique point in the graph)
- How to I plot labels and ticks on both sides (or top and bottom) of
 the coordinate system?
- How do I use (and properly label) a logarithmically scaled color
 scale?
- How can I label the axes in imshow logarithmically?
- How do I produce a QQ-plot?
- How do I produce figures such that the font size, when included into
 a TeX document, matches the font size of the text?
- How do I mask invalid regions in imshow()? 
Here, I believe it would be important that the examples are
accompanied by explanatory text. Sometimes these tricks are obvious
from the code itself, but sometimes a more high-level explanation
would really help a lot.
For category 3, I would only take examples of exceptional quality, and
also, if possible, with explanation of the task, of solution
strategies, and possibly references to publications where the output
has appeared (on wikipedia, there seem to be a good number of high
quality plots which appear to come from matplotlib but which do not
have source code attached, so some cross-linking could be worthwhile).
The last item of concern to me is the quality of gallery pictures.
While there are excellent examples, most have more or less glaring
deficiencies. Some issues appear to point to bugs or at least
limitations of matplotlib itself. What is absolutely necessary is a
very critical review. Let me just pick a more or less randomly chosen
gallery item, sankey_demo_basics.py:
- Annotations run into each other, into the flow graph, and into the
 coordinate frame
- Distance of annotations to flow graph inconsistent and often too
 small
- About half way between the label "0.6" and "0.15", the boundary of
 the flow graph appears to be double-printed with a slightly thicker
 line.
- On the third plot, the flow graph seems down-shifted and the legend
 is cramped
I could easily come up with similar lists of very many of the other
graphs (in fact, I might even volunteer to do this systematically if
there is a process on how to file and document such observations so
that the effort could not get lost).
Another effort should be to remove redundancy, the question should
always be "is this the best way to demonstrate this feature", if there
is a better way, the inferior one should be removed. The gallery has
already reached a size where finding things is difficult, so the
overall growth should be in quality, not in quantity.
Just my 2 cents... As I said, I would be willing to help out mainly
with reviewing.
Regards,
Marcel
---------------------------------------------------------------------
Marcel Oliver Phone: +49-421-200-3212 
School of Engineering and Science Fax: +49-421-200-3103
Jacobs University m.o...@ja...
Campus Ring 1 ol...@me... 
28759 Bremen, Germany http://math.jacobs-university.de/oliver
---------------------------------------------------------------------

On Tue, Dec 11, 2012 at 4:15 AM, Phil Elson <pel...@gm...> wrote:
> > I'm not sure if non-core-developers are allowed to post MEPs, but I just
> did
>
> Yes please... The more the merrier!
> Aren't you a core dev anyway Tony? :-) You've certainly contributed some
> really valuable features, and even if you don't have access to "the big
> green button" in my eyes you feedback and input are just as valuable.
>
Thanks :)
<snip>
One thing I was considering doing in my implementation was allowing
> multiple tags for each example by adding some extra module level
> information (in a list called "__tags__" perhaps) rather than focussing on
> a directory structure to provide the tag as the current implementation of
> the gallery does (and as far as I can see, the MEP recommends this too).
>
I think tags would be great, but I don't want to be responsible for
implementing them :). As argued in the MEP, tags would be complementary:
Sections would help users who just want to scan the gallery. Maybe we can
"suggest" that clean ups include tags as a way of preparing for the future?
> In the past I have also worked on a gallery extension which uses the
> docstring of the example to provide a richer explanation of what is going
> on (example:
> http://scitools.org.uk/iris/docs/latest/examples/graphics/COP_1d_plot.html).
> An alternative approach which has worked well for me is the walked through
> examples found in scikits-learn (their website is down, but most of the
> examples are good in that regard) which could be done via an iPython
> notebook for the annotations.
Actually, scikit-image borrowed the scikit-learn gallery extension, and I
ended up tweaking it to provide more control over the output:
http://tonysyu.github.com/mpltools/auto_examples/sphinx/plot_plot2rst.html
I haven't looked too closely at the machinery used to generate the
matplotlib gallery, so I'm not sure how difficult it will be to integrate
something like this.
Best,
-Tony

On Tue, Dec 11, 2012 at 2:07 AM, Nicolas Rougier
<Nic...@in...>wrote:
>
>
> Thanks a lot for this MEP and I would gladly contribute to the new gallery.
>
Thanks for adding the link to your gallery. I meant to include it (that's
where I got the idea for a "showcase" section) but it slipped through.
> From my own experience with the current gallery, I would recommend to have
> simple scripts that illustrate one feature only, it make things more clear
> IMHO.
I definitely agree. That's more clearly stated in the MEP, now.
> From my attempt at making some alternative gallery (
> http://www.loria.fr/~rougier/coding/gallery/), I would also recommend a
> standard size for figures unless a different size is strictly necessary.
I agree, but I'm not sure if this should be controlled by the example
script, or if the thumbnail generator should force a specific thumbnail
size. Regardless, most examples shouldn't be changing the default figure
size (since they should be focused on changes pertinent to a single
function).
> For section names, maybe we can use several different schemes with same
> figures ?
I think this would be better suited for a tagging system, which I think is
complementary to the gallery sections. I believe Ben started working on a
tagging system, but then life got in the way :)
Also, one important thing is to have a page with all the figures such one
> can browse visually all the examples.
>
 Agreed. I don't think the idea of the gallery should change---just the
organization of it.
Cheers,
-Tony