matplotlib-devel Mailing List for matplotlib (Page 3)

On 11 December 2012 23:07, Tony Yu <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.
>>
>
> 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.
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.
Best wishes,
Thomas

Hi Michael,
Thanks for reading the MEP! Responses below:
On Tue, Dec 11, 2012 at 1:10 PM, Michael Droettboom <md...@st...> wrote:
> On 12/10/2012 05:18 PM, Tony Yu wrote:
>
> <snip>
> MEP 12 outlines the reorganization of the example gallery and subsequent
> clean up of the examples:
>
>
> https://github.com/matplotlib/matplotlib/wiki/MEP12
>
> In my opinion, there are two open questions in the MEP:
>
> * Section names (may seem trivial to some, but I think it's really
> important)
> * Guidelines for cleaning up examples
>
> Some thoughts:
>
> 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.
>
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.
As for the categories/structure, I think I prefer your "suggested
> alternative" -- to have narrowly defined categories rather than a big
> "plotting" directory.
>
I agree that "plotting" is too general. My only hesitation with the finer
classification of plots is that it's really hard to come up with categories
that work; my current suggestions in the MEP aren't really ideal.
Nevertheless, I'm sure we can all put our heads together to come up with
categories that make sense...
> For "cleanup guidelines", perhaps it is worth mentioning that some of the
> examples are really unit tests -- they just exercise some esoteric feature
> that's only of interest to developers. These should be converted into unit
> tests from the framework and probably deleted altogether as gallery
> examples.
>
Agreed.
Maybe we should also add that examples should be renamed when appropriate:
> there are things like "image_demo.py" and "image_demo2.py". The "2"
> doesn't really help to describe what's in there.
>
I definitely agree.
I'm not sure I agree with "one figure per example" as a goal -- it is
> sometimes nice to have a number of features demonstrated by a single
> example file, and cramming them all into multiple axes isn't always the
> best approach. I think we can take that on a case-by-case basis.
>
I was hesitant to add this initially. I agree it's sometimes a good idea to
have multiple figures. I'd still like to have this as a suggestion---I'll
try to make that a little clearer in the MEP.
> I agree with Phil that we might as well just iterate this on master. I
> would envision one or two PRs to get the general infrastructure in place,
> and then lots of PRs from multiple authors as we work on whipping the
> examples into shape.
>
Sounds good.
Best,
-Tony

Hi Russell,
On Tue, Dec 11, 2012 at 3:14 PM, Russell E. Owen <ro...@uw...> wrote:
> I have not yet made them, but it's on my to do list. One problem is that
> there are so many flavors of Python 3 (version 3.2, version 3.3, each in
> two flavors: for MacOS X 10.5 and later and for MacOS 10.6 and later).
> Anyone have suggestions for easily building against multiple versions of
> python?
thanks for the info, I totally understand the effort involved and
we're all super grateful that you put in this work in the first place!
Best,
f

In article 
<CAHAreOoB8coDnyvU1Zq2iOdGqYr2p2t-m=gV=uV5...@ma...>,
 Fernando Perez <fpe...@gm...> 
 wrote:
> Hi folks,
> 
> quick question; on the downloads page
> (https://github.com/matplotlib/matplotlib/downloads) I only see py27
> OSX binaries; is there any official location for Py3 ones? I just had
> a colleague ask me about them and I couldn't find any in the places
> I'm used to searching for (github, pypi, superpack).
I have not yet made them, but it's on my to do list. One problem is that 
there are so many flavors of Python 3 (version 3.2, version 3.3, each in 
two flavors: for MacOS X 10.5 and later and for MacOS 10.6 and later). 
Anyone have suggestions for easily building against multiple versions of 
python?
- Russell

On 12/10/2012 05:18 PM, Tony Yu wrote:
> Hi all,
>
> I'm not sure if non-core-developers are allowed to post MEPs, but I 
> just did ;).
It's a big tent. Come on in! BTW -- if you want to have access to the 
big green merge button, let me know. You've certainly been working on 
matplotlib long enough, to say the least. :)
> MEP 12 outlines the reorganization of the example gallery and 
> subsequent clean up of the examples:
>
> https://github.com/matplotlib/matplotlib/wiki/MEP12
>
> In my opinion, there are two open questions in the MEP:
>
> * Section names (may seem trivial to some, but I think it's really 
> important)
> * Guidelines for cleaning up examples
>
Some thoughts:
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.
As for the categories/structure, I think I prefer your "suggested 
alternative" -- to have narrowly defined categories rather than a big 
"plotting" directory.
For "cleanup guidelines", perhaps it is worth mentioning that some of 
the examples are really unit tests -- they just exercise some esoteric 
feature that's only of interest to developers. These should be 
converted into unit tests from the framework and probably deleted 
altogether as gallery examples.
Maybe we should also add that examples should be renamed when 
appropriate: there are things like "image_demo.py" and 
"image_demo2.py". The "2" doesn't really help to describe what's in there.
I'm not sure I agree with "one figure per example" as a goal -- it is 
sometimes nice to have a number of features demonstrated by a single 
example file, and cramming them all into multiple axes isn't always the 
best approach. I think we can take that on a case-by-case basis.
I agree with Phil that we might as well just iterate this on master. I 
would envision one or two PRs to get the general infrastructure in 
place, and then lots of PRs from multiple authors as we work on whipping 
the examples into shape.
Note that I haven't started doing this yet, but I will probably start 
periodically posting built documentation of master on the website -- 
that should make it easy for anyone to preview the new gallery and 
provide feedback as we work.
Cheers,
Mike

On 10 December 2012 22:43, Tony Yu <ts...@gm...> wrote:
> This MEP only concerns the main gallery. I think user-contributed examples
> were (are?) the intended focus of SciPy Central:
>
> http://scipy-central.org/
>
> (and before that, the SciPy Cookbook). I'm not sure about the status of
> SciPy Central. There was talk of a redesign, but I haven't seen any
> progress since then.
>
We (IPython) contacted the maintainer of Scipy Central. The picture is
roughly that he doesn't have time to maintain it, but is happy to transfer
the codebase and content (and server? I can't remember) to anyone who's
interested.
We've also got an idea about making a site for sharing code samples based
on http://nbviewer.ipython.org/ , as the notebook is a format that really
lends itself to this sort of thing.
Best wishes,
Thomas

Hi folks,
quick question; on the downloads page
(https://github.com/matplotlib/matplotlib/downloads) I only see py27
OSX binaries; is there any official location for Py3 ones? I just had
a colleague ask me about them and I couldn't find any in the places
I'm used to searching for (github, pypi, superpack).
thanks,
f

Thanks a lot for this MEP and I would gladly contribute to the new gallery.
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. 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.
For section names, maybe we can use several different schemes with same figures ?
Also, one important thing is to have a page with all the figures such one can browse visually all the examples.
Nicolas
On Dec 11, 2012, at 0:00 , Tony Yu wrote:
> 
> 
> On Mon, Dec 10, 2012 at 5:51 PM, Paul Hobson <pmh...@gm...> wrote:
> On Mon, Dec 10, 2012 at 2:18 PM, Tony Yu <ts...@gm...> wrote:
> Hi all,
> 
> I'm not sure if non-core-developers are allowed to post MEPs, but I just did ;). MEP 12 outlines the reorganization of the example gallery and subsequent clean up of the examples:
> 
> https://github.com/matplotlib/matplotlib/wiki/MEP12
> 
> In my opinion, there are two open questions in the MEP:
> 
> * Section names (may seem trivial to some, but I think it's really important)
> * Guidelines for cleaning up examples
> 
> I've added proposed section names and clean-up guidelines to the MEP, but I'm sure these will evolve over time.
> 
> Best,
> -Tony
> 
> 
> Here here! I've been waiting for a really nasty, cold, and rainy weekend here in Portland to make some PRs at least cleaning up the code contained within the examples. Just hasn't happened yet ;)
> 
> Tony, if you make your own branch for this, I'd be happy to contribute.
> -paul 
> 
> Awesome! I'm hoping we can quickly converge on some clean-up guidelines and section headings. 
> 
> I was envisioning a single PR that adds new gallery sections. After that examples would be updated over a long period of time in multiple PRs that change a few examples at a time. Do you think that all the work should be done on a parallel branch and merged in one big PR?
> 
> Best,
> -Tony
> ------------------------------------------------------------------------------
> 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

> 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.
The gallery was one of the key features that pulled me into mpl, but it
definitely needs a bit of TLC. The timing is quite convenient for me as I
am about to (in the next month or so) embark on implementing a gallery for
a project I'm working on that makes heavy use of matplotlib (cartopy:
http://scitools.org.uk/cartopy/docs/latest/).
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).
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.
> Do you think that all the work should be done on a parallel branch and
merged in one big PR?
Personally, I'm not in favour of that. We would have to make sure that the
pull requests related to this change don't start to stack up, but I think
we can definitely do this sequentially once the appropriate machinery is in
place.
Thanks for bringing this subject up,
All the best,
Phil
On 10 December 2012 23:00, Tony Yu <ts...@gm...> wrote:
>
>
> On Mon, Dec 10, 2012 at 5:51 PM, Paul Hobson <pmh...@gm...> wrote:
>
>> On Mon, Dec 10, 2012 at 2:18 PM, Tony Yu <ts...@gm...> wrote:
>>
>>> Hi all,
>>>
>>> I'm not sure if non-core-developers are allowed to post MEPs, but I just
>>> did ;). MEP 12 outlines the reorganization of the example gallery and
>>> subsequent clean up of the examples:
>>>
>>> https://github.com/matplotlib/matplotlib/wiki/MEP12
>>>
>>> In my opinion, there are two open questions in the MEP:
>>>
>>> * Section names (may seem trivial to some, but I think it's really
>>> important)
>>> * Guidelines for cleaning up examples
>>>
>>> I've added proposed section names and clean-up guidelines to the MEP,
>>> but I'm sure these will evolve over time.
>>>
>>> Best,
>>> -Tony
>>>
>>>
>> Here here! I've been waiting for a really nasty, cold, and rainy weekend
>> here in Portland to make some PRs at least cleaning up the code contained
>> within the examples. Just hasn't happened yet ;)
>>
>> Tony, if you make your own branch for this, I'd be happy to contribute.
>> -paul
>>
>
> Awesome! I'm hoping we can quickly converge on some clean-up guidelines
> and section headings.
>
> I was envisioning a single PR that adds new gallery sections. After that
> examples would be updated over a long period of time in multiple PRs that
> change a few examples at a time. Do you think that all the work should be
> done on a parallel branch and merged in one big PR?
>
> Best,
> -Tony
>
>
> ------------------------------------------------------------------------------
> 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 Wed, Dec 5, 2012 at 10:23 PM, Paul Ivanov <piv...@gm...> wrote:
> On Wed, Dec 5, 2012 at 1:52 PM, Nathaniel Smith <nj...@po...> wrote:
>> If you're defining your own warning class, you might consider using
>> FutureWarning instead of UserWarning.
>>
>> We had a discussion about this issue for numpy recently:
>> http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062460.html
>> What we eventually ended up with:
>> http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062468.html
>
> Thanks for the pointers, Nathaniel. Though I think I disagree with
> continuing to use DeprecationWarnings for features that will go away
> and just break code - shouldn't users be given ample opportunity of
> coming changes without having to find out by having their code break
> at a future release?
Yeah, there aren't any perfect solutions here. That's why I didn't
express an opinion on what you ought to do :-).
Basically what the debate comes down to is, deprecation warnings are
useful to developers, and annoying and scary to users. (And users can
easily end up seeing them, e.g. if they use a package which depends on
matplotlib, and then upgrade matplotlib, their existing package may
suddenly start spewing scary warnings, and that package's developers
can't do anything about this because this version of matplotlib is
newer than anything that existed when they released their package.)
This problem becomes worse the lower your package is in the stack, and
the more widely used it is by third-party packages.
It's easier to tell developers how to turn on deprecation warnings
than it is to tell users how to turn them off, so that's why the
Python stdlib turned them off by default, and similarly numpy.
The main thing I took from this personally is that I went and added
'export PYTHONWARNINGS=default' to all my package's test scripts, to
ensure deprecation warnings would be enabled...
-n

On Mon, Dec 10, 2012 at 5:51 PM, Paul Hobson <pmh...@gm...> wrote:
> On Mon, Dec 10, 2012 at 2:18 PM, Tony Yu <ts...@gm...> wrote:
>
>> Hi all,
>>
>> I'm not sure if non-core-developers are allowed to post MEPs, but I just
>> did ;). MEP 12 outlines the reorganization of the example gallery and
>> subsequent clean up of the examples:
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP12
>>
>> In my opinion, there are two open questions in the MEP:
>>
>> * Section names (may seem trivial to some, but I think it's really
>> important)
>> * Guidelines for cleaning up examples
>>
>> I've added proposed section names and clean-up guidelines to the MEP, but
>> I'm sure these will evolve over time.
>>
>> Best,
>> -Tony
>>
>>
> Here here! I've been waiting for a really nasty, cold, and rainy weekend
> here in Portland to make some PRs at least cleaning up the code contained
> within the examples. Just hasn't happened yet ;)
>
> Tony, if you make your own branch for this, I'd be happy to contribute.
> -paul
>
Awesome! I'm hoping we can quickly converge on some clean-up guidelines and
section headings.
I was envisioning a single PR that adds new gallery sections. After that
examples would be updated over a long period of time in multiple PRs that
change a few examples at a time. Do you think that all the work should be
done on a parallel branch and merged in one big PR?
Best,
-Tony

thanks Tony. I didn't know this before.
On Mon, Dec 10, 2012 at 11:32 PM, Chao YUE <cha...@gm...> wrote:
> The gallry will not include everything, could we also have somewhere to
> let "non-core" users freely share the code? like some features that are
> nice to have but not easily found in the galery? but hope this will not
> lead to overcrowded.
>
> Chao
>
> On Mon, Dec 10, 2012 at 11:18 PM, Tony Yu <ts...@gm...> wrote:
>
>> Hi all,
>>
>> I'm not sure if non-core-developers are allowed to post MEPs, but I just
>> did ;). MEP 12 outlines the reorganization of the example gallery and
>> subsequent clean up of the examples:
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP12
>>
>> In my opinion, there are two open questions in the MEP:
>>
>> * Section names (may seem trivial to some, but I think it's really
>> important)
>> * Guidelines for cleaning up examples
>>
>> I've added proposed section names and clean-up guidelines to the MEP, but
>> I'm sure these will evolve over time.
>>
>> Best,
>> -Tony
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> --
>
> ***********************************************************************************
> Chao YUE
> Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
> UMR 1572 CEA-CNRS-UVSQ
> Batiment 712 - Pe 119
> 91191 GIF Sur YVETTE Cedex
> Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
>
> ************************************************************************************
>
>
-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
************************************************************************************

On Mon, Dec 10, 2012 at 2:18 PM, Tony Yu <ts...@gm...> wrote:
> Hi all,
>
> I'm not sure if non-core-developers are allowed to post MEPs, but I just
> did ;). MEP 12 outlines the reorganization of the example gallery and
> subsequent clean up of the examples:
>
> https://github.com/matplotlib/matplotlib/wiki/MEP12
>
> In my opinion, there are two open questions in the MEP:
>
> * Section names (may seem trivial to some, but I think it's really
> important)
> * Guidelines for cleaning up examples
>
> I've added proposed section names and clean-up guidelines to the MEP, but
> I'm sure these will evolve over time.
>
> Best,
> -Tony
>
>
Here here! I've been waiting for a really nasty, cold, and rainy weekend
here in Portland to make some PRs at least cleaning up the code contained
within the examples. Just hasn't happened yet ;)
 Tony, if you make your own branch for this, I'd be happy to contribute.
-paul

On Mon, Dec 10, 2012 at 5:32 PM, Chao YUE <cha...@gm...> wrote:
> The gallry will not include everything, could we also have somewhere to
> let "non-core" users freely share the code? like some features that are
> nice to have but not easily found in the galery? but hope this will not
> lead to overcrowded.
>
> Chao
>
Hi Chao,
This MEP only concerns the main gallery. I think user-contributed examples
were (are?) the intended focus of SciPy Central:
 http://scipy-central.org/
(and before that, the SciPy Cookbook). I'm not sure about the status of
SciPy Central. There was talk of a redesign, but I haven't seen any
progress since then.
 Best,
-Tony
> On Mon, Dec 10, 2012 at 11:18 PM, Tony Yu <ts...@gm...> wrote:
>
>> Hi all,
>>
>> I'm not sure if non-core-developers are allowed to post MEPs, but I just
>> did ;). MEP 12 outlines the reorganization of the example gallery and
>> subsequent clean up of the examples:
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP12
>>
>> In my opinion, there are two open questions in the MEP:
>>
>> * Section names (may seem trivial to some, but I think it's really
>> important)
>> * Guidelines for cleaning up examples
>>
>> I've added proposed section names and clean-up guidelines to the MEP, but
>> I'm sure these will evolve over time.
>>
>> Best,
>> -Tony
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> --
>
> ***********************************************************************************
> Chao YUE
> Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
> UMR 1572 CEA-CNRS-UVSQ
> Batiment 712 - Pe 119
> 91191 GIF Sur YVETTE Cedex
> Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
>
> ************************************************************************************
>
>

The gallry will not include everything, could we also have somewhere to let
"non-core" users freely share the code? like some features that are nice to
have but not easily found in the galery? but hope this will not lead to
overcrowded.
Chao
On Mon, Dec 10, 2012 at 11:18 PM, Tony Yu <ts...@gm...> wrote:
> Hi all,
>
> I'm not sure if non-core-developers are allowed to post MEPs, but I just
> did ;). MEP 12 outlines the reorganization of the example gallery and
> subsequent clean up of the examples:
>
> https://github.com/matplotlib/matplotlib/wiki/MEP12
>
> In my opinion, there are two open questions in the MEP:
>
> * Section names (may seem trivial to some, but I think it's really
> important)
> * Guidelines for cleaning up examples
>
> I've added proposed section names and clean-up guidelines to the MEP, but
> I'm sure these will evolve over time.
>
> Best,
> -Tony
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
************************************************************************************

Hi all,
I'm not sure if non-core-developers are allowed to post MEPs, but I just
did ;). MEP 12 outlines the reorganization of the example gallery and
subsequent clean up of the examples:
 https://github.com/matplotlib/matplotlib/wiki/MEP12
In my opinion, there are two open questions in the MEP:
 * Section names (may seem trivial to some, but I think it's really
important)
 * Guidelines for cleaning up examples
I've added proposed section names and clean-up guidelines to the MEP, but
I'm sure these will evolve over time.
Best,
-Tony

 Hi,
 Recently I asked to become comaintainer of matplotlib in Fedora and
did update to 1.2.0
for the upcoming f18 and rawhide.
 I am also working on an experimental sagemath package that I hope to
get in f19 and
make a backport to f18. One example of the font problem is:
--%<---%<--%<---%<--%<---%<--%<---%<--%<---%<--%<---%<--%<---%<--%<---%<--%<---
$ sage -t -force_lib "devel/sage/sage/geometry/cone.py"
sage -t -force_lib "devel/sage/sage/geometry/cone.py"
**********************************************************************
File "/usr/lib64/sagemath/devel/sage/sage/geometry/cone.py", line 930:
 sage: quadrant.plot()
Expected nothing
Got:
 doctest:1214: UserWarning: findfont: Font family ['STIXGeneral']
not found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family
['STIXSizeOneSym'] not found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family
['STIXSizeThreeSym'] not found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family
['STIXSizeFourSym'] not found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family
['STIXSizeFiveSym'] not found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family
['STIXSizeTwoSym'] not found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family
['STIXNonUnicode'] not found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family ['cmb10'] not
found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family ['cmtt10'] not
found. Falling back to Bitstream Vera Sans
 doctest:1214: UserWarning: findfont: Font family ['cmss10'] not
found. Falling back to Bitstream Vera Sans
 <BLANKLINE>
**********************************************************************
1 items had failures:
 1 of 5 in __main__.example_17
***Test Failed*** 1 failures.
For whitespace errors, see the file /home/pcpa/.sage/tmp/cone_4295.py
 [5.8 s]
----------------------------------------------------------------------
The following tests failed:
 sage -t -force_lib "devel/sage/sage/geometry/cone.py"
Total time for all tests: 5.9 seconds
--%<---%<--%<---%<--%<---%<--%<---%<--%<---%<--%<---%<--%<---%<--%<---%<--%<---
 I opened two bug reports about it at:
https://bugzilla.redhat.com/show_bug.cgi?id=885307 and
https://bugzilla.redhat.com/show_bug.cgi?id=885312
It "works", that is, is silent in f17, but it should be because f17
has stix fonts
1.0.0 and f18+ has stix-fonts 1.1.0. I am not sure how to correct it, so, an
experimental hack patch "to make it silent" is:
---%<---
--- /usr/lib64/python2.7/site-packages/matplotlib/mathtext.py.orig	2012年12月08日
15:16:23.959250860 -0200
+++ /usr/lib64/python2.7/site-packages/matplotlib/mathtext.py	2012年12月08日
15:31:51.404286375 -0200
@@ -670,10 +670,7 @@
 """
 _fontmap = { 'cal' : 'cmsy10',
 'rm' : 'cmr10',
- 'tt' : 'cmtt10',
 'it' : 'cmmi10',
- 'bf' : 'cmb10',
- 'sf' : 'cmss10',
 'ex' : 'cmex10'
 }
@@ -902,19 +899,9 @@
 - handles sized alternative characters for the STIXSizeX fonts.
 """
- _fontmap = { 'rm' : 'STIXGeneral',
- 'it' : 'STIXGeneral:italic',
- 'bf' : 'STIXGeneral:weight=bold',
- 'nonunirm' : 'STIXNonUnicode',
- 'nonuniit' : 'STIXNonUnicode:italic',
- 'nonunibf' : 'STIXNonUnicode:weight=bold',
-
- 0 : 'STIXGeneral',
- 1 : 'STIXSizeOneSym',
- 2 : 'STIXSizeTwoSym',
- 3 : 'STIXSizeThreeSym',
- 4 : 'STIXSizeFourSym',
- 5 : 'STIXSizeFiveSym'
+ _fontmap = { 'rm' : 'STIX:regular',
+ 'it' : 'STIX:italic',
+ 'bf' : 'STIX:weight=bold'
 }
 use_cmex = False
 cm_fallback = False
---%<---
but this absolutely does not look right and proper to add to the f18+ matplotlib
package.
Any suggestion on how to properly correct it is welcome.
Thanks,
Paulo

Did everyone see that GitHub now allows attachments in issue comments?
IMO, this is awesome. Attaching a visual *thing* of output when users
get unexpected results from plotting calls is a massive plus. Drag and
drop right into the browser, too! No more having to upload a file to
imgur or dropbox and link it to the issue comment and then have it
disappear when you delete it and forgot it was linked to GitHub.
Win.
-- 
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

Yes, an excellent summary and neatly bringing us back to the crux of the
matter.
For completeness I should say that I wouldn't use SWIG. I used it about 5
years ago to wrap some C++ for Python and other languages. Initially it
was very useful, but eventually the default mapping between C++ and Python
types and the default handling of object lifetimes weren't quite what I
wanted and I found myself writing a lot of extra configuration code to coax
it back in line. In the end I went back to the Python/C API. Perhaps its
aim of targetting many different languages means it isn't suited for our
language of interest. It doesn't support Numpy arrays anyway.
I would like to be able to recommend Boost.Python, but I have never used
it. I have used some Boost modules and found all to be well-designed and
actively maintained. However, it currently doesn't support Numpy arrays
(although it is an active area of work) and it appears that there are
difficulties building it with anything other than the default build tool
BJam leading to concerns over portability.
Although my preference, in the absence of PyCXX, for wrapping our larger
C/C++ modules is to use the Python/C API rather than Cython, I have been
persuaded that there is a place for Cython in matplotlib. The ability to
improve the performance of small sections of Python code in a simple and
localised manner seems very useful, and would be a good starting point for
speeding up areas of code that a number of users are frustrated by. Given
the number of people who would like to see it used in matplotlib, I think
it is inevitable that we eventually will.
I hadn't really considered the option of adding Numpy arrays to PyCXX.
I've taken a quick look at the existing code and whilst I don't think it is
a trivial task it looks well worth investigating - the existing code is
well organised and quite well documented. If two or more of us were
prepared to make the Numpy additions to PyCXX and provide ongoing
maintenance, we would address the deficiencies of the current solution and
remove the single-person bottleneck. But I am not sure where this leaves
us as I a now advocating use of Cython to some extent and hence we would
have two wrapping tools. Should we reject Cython + improved PyCXX on these
grounds and revert to Cython + Python/C API?
Ian

On 2012年12月06日 7:16 AM, Michael Droettboom wrote:
> I think this has been a very helpful and useful discussion.
>
> I'm going to attempt to summarize this discussion and propose some ways
> forward here.
>
> The impetus for this discussion is that PyCXX seems to be not adequately
> maintained. It is difficult to build matplotlib with "vanilla" PyCXX in
> certain configurations. (This history sort of predates this thread).
>
> So we have some options:
>
> 1) One way forward is to offer to take ownership of the PyCXX project.
> (I'm not using the "f" word here... I'd much prefer to just become more
> involved upstream somehow). I don't think this would be considerable
> additional work, as most of that work has been done in matplotlib for
> some time anyway. To the extent that it needs new features, it would be
> killer to add support for Numpy so Numpy no longer required manual
> reference counting. I had initially dismissed this approach, as I seem
> to be in the minority in liking PyCXX -- I happen to think it's
> fundamentally an extremely good approach to the problem: it helps with
> reference counting errors, but otherwise mostly stays out of the way.
> But I'd like to remove any one person as a bottleneck by choosing
> something that's more preferred all around.
>
> 2) Move to a different wrapping mechanism of some sort. While Cython is
> the clear choice for a third-party Python/C wrapping tool, it seems to
> be polarizing. (I won't attempt to repeat or summarize, but I think
> good points have been made on either side of the argument). I think
> it's ok to allow Cython to be used in matplotlib, given that we include
> both the Cython source and the generated C in the source repository such
> that matplotlib can be built without Cython installed. There are many
> other projects doing this that can provide best practices for us. I
> don't think, however, that we can or should require that all wrapping is
> done with Cython. I think we should allow raw Python/C API where it is
> most appropriate (and that is mainly in the case of wrapping third-party
> libraries, such as the png module and the macosx module which is already
> raw Python/C API). What I wouldn't want to see is the use of more than
> one wrapping tool, if only for reasons of proliferation of dependencies.
> (I count the Python/C API as "free" since it's always available
> anyway). I haven't seen in this discussion anyone really pushing for
> any of the alternatives (SWIG, Boost.Python, etc.) in any event.
>
> Note also, the goal is to deal with the PyCXX "problem", not rewrite
> large chunks of our existing and well-tested C/C++ code base in Cython,
> unless someone sees a real clear benefit to doing that for a particular
> module and is highly motivated to do the work. This is primarily about
> refactoring the code so that the interface layer between Python and C is
> separated and then replaced with either Cython or raw Python/C API using
> the most appropriate tool for the job.
>
> 3) Any other options...?
>
> Cheers,
> Mike
Mike,
That is an excellent summary. The options actually are not mutually 
exclusive; perhaps what we are considering is more in the line of 
nudging evolution in one direction or the other, not pushing for rapid 
extinction of a species.
Regarding PyCXX, I respect your opinion that it is a good match for what 
it does. To the limited extent that I can work with C++ at all, I don't 
have any problem with its use in mpl. I do share the concern about 
depending heavily on it, given that problems with it have cropped up, 
and you have been the only one willing and able to deal with those 
problems. Since PyCXX is a pure C++ construct, perhaps other C++ 
gurus--and it seems that we now have more than previously--would be 
willing to take a closer look at it, and reconsider whether they can 
relieve the single-person-bottleneck problem.
There is always a tradeoff between going to a higher-level language or 
library versus sticking with lower levels. Personally, I like C over 
C++ because the former is simple enough that I can generally figure out 
what is going on; but I like Cython over raw Python/C API because its 
internal complexity allows an external simplicity, hiding all sorts of 
things I really don't want to have to think about. Going to higher 
levels always brings the risk of dependency on a complex system, whether 
it be Cython or PyCXX or Agg, or even the C/C++ compiler itself. The 
cost/benefit ratios of such tradeoffs vary greatly with the situation, 
and from person to person, depending on training, experience, and 
personal quirks. So we just have to keep looking for the balance that 
is appropriate to the task, the times, and the people at hand. Your 
summary nicely facilitates that balancing act.
Eric

Just for completeness, there is also ctypes. I wrapped the freetype library (http://code.google.com/p/freetype-py/) using it and it is quite easy (and boring). But this only works for C (not C++).
Nicolas
On Dec 6, 2012, at 18:06 , Michael Droettboom wrote:
> I think this has been a very helpful and useful discussion.
> 
> I'm going to attempt to summarize this discussion and propose some ways 
> forward here.
> 
> The impetus for this discussion is that PyCXX seems to be not adequately 
> maintained. It is difficult to build matplotlib with "vanilla" PyCXX in 
> certain configurations. (This history sort of predates this thread).
> 
> So we have some options:
> 
> 1) One way forward is to offer to take ownership of the PyCXX project. 
> (I'm not using the "f" word here... I'd much prefer to just become more 
> involved upstream somehow). I don't think this would be considerable 
> additional work, as most of that work has been done in matplotlib for 
> some time anyway. To the extent that it needs new features, it would be 
> killer to add support for Numpy so Numpy no longer required manual 
> reference counting. I had initially dismissed this approach, as I seem 
> to be in the minority in liking PyCXX -- I happen to think it's 
> fundamentally an extremely good approach to the problem: it helps with 
> reference counting errors, but otherwise mostly stays out of the way. 
> But I'd like to remove any one person as a bottleneck by choosing 
> something that's more preferred all around.
> 
> 2) Move to a different wrapping mechanism of some sort. While Cython is 
> the clear choice for a third-party Python/C wrapping tool, it seems to 
> be polarizing. (I won't attempt to repeat or summarize, but I think 
> good points have been made on either side of the argument). I think 
> it's ok to allow Cython to be used in matplotlib, given that we include 
> both the Cython source and the generated C in the source repository such 
> that matplotlib can be built without Cython installed. There are many 
> other projects doing this that can provide best practices for us. I 
> don't think, however, that we can or should require that all wrapping is 
> done with Cython. I think we should allow raw Python/C API where it is 
> most appropriate (and that is mainly in the case of wrapping third-party 
> libraries, such as the png module and the macosx module which is already 
> raw Python/C API). What I wouldn't want to see is the use of more than 
> one wrapping tool, if only for reasons of proliferation of 
> dependencies. (I count the Python/C API as "free" since it's always 
> available anyway). I haven't seen in this discussion anyone really 
> pushing for any of the alternatives (SWIG, Boost.Python, etc.) in any event.
> 
> Note also, the goal is to deal with the PyCXX "problem", not rewrite 
> large chunks of our existing and well-tested C/C++ code base in Cython, 
> unless someone sees a real clear benefit to doing that for a particular 
> module and is highly motivated to do the work. This is primarily about 
> refactoring the code so that the interface layer between Python and C is 
> separated and then replaced with either Cython or raw Python/C API using 
> the most appropriate tool for the job.
> 
> 3) Any other options...?
> 

I think this has been a very helpful and useful discussion.
I'm going to attempt to summarize this discussion and propose some ways 
forward here.
The impetus for this discussion is that PyCXX seems to be not adequately 
maintained. It is difficult to build matplotlib with "vanilla" PyCXX in 
certain configurations. (This history sort of predates this thread).
So we have some options:
1) One way forward is to offer to take ownership of the PyCXX project. 
(I'm not using the "f" word here... I'd much prefer to just become more 
involved upstream somehow). I don't think this would be considerable 
additional work, as most of that work has been done in matplotlib for 
some time anyway. To the extent that it needs new features, it would be 
killer to add support for Numpy so Numpy no longer required manual 
reference counting. I had initially dismissed this approach, as I seem 
to be in the minority in liking PyCXX -- I happen to think it's 
fundamentally an extremely good approach to the problem: it helps with 
reference counting errors, but otherwise mostly stays out of the way. 
But I'd like to remove any one person as a bottleneck by choosing 
something that's more preferred all around.
2) Move to a different wrapping mechanism of some sort. While Cython is 
the clear choice for a third-party Python/C wrapping tool, it seems to 
be polarizing. (I won't attempt to repeat or summarize, but I think 
good points have been made on either side of the argument). I think 
it's ok to allow Cython to be used in matplotlib, given that we include 
both the Cython source and the generated C in the source repository such 
that matplotlib can be built without Cython installed. There are many 
other projects doing this that can provide best practices for us. I 
don't think, however, that we can or should require that all wrapping is 
done with Cython. I think we should allow raw Python/C API where it is 
most appropriate (and that is mainly in the case of wrapping third-party 
libraries, such as the png module and the macosx module which is already 
raw Python/C API). What I wouldn't want to see is the use of more than 
one wrapping tool, if only for reasons of proliferation of dependencies. 
 (I count the Python/C API as "free" since it's always available 
anyway). I haven't seen in this discussion anyone really pushing for 
any of the alternatives (SWIG, Boost.Python, etc.) in any event.
Note also, the goal is to deal with the PyCXX "problem", not rewrite 
large chunks of our existing and well-tested C/C++ code base in Cython, 
unless someone sees a real clear benefit to doing that for a particular 
module and is highly motivated to do the work. This is primarily about 
refactoring the code so that the interface layer between Python and C is 
separated and then replaced with either Cython or raw Python/C API using 
the most appropriate tool for the job.
3) Any other options...?
Cheers,
Mike
On 12/04/2012 05:33 PM, Eric Firing wrote:
> On 2012年12月04日 12:07 PM, Damon McDougall wrote:
>> On Mon, Dec 3, 2012 at 12:12 PM, Chris Barker - NOAA Federal
>> <chr...@no...> wrote:
>>> generated code is ugly and hard to maintain, it is not designed to be
>>> human-readable, and we wouldn't get the advantages of bug-fixes
>>> further development in Cython.
>> As far as I'm concerned, this is an argument against Cython.
> Nonsense. It is an argument against the idea of maintaining the
> generated code directly, rather than maintaining the cython source code
> and regenerating the C code as needed. That idea never made any sense
> in the first place. I doubt that anyone follows it. Chris already
> pointed this out. Would you maintain the assembly code generated by
> your C++ compiler? Do you consider the fact that this is unreadable and
> unmaintainable a reason to avoid using that compiler, and instead to
> code directly in assembly?
>
>> I've had to touch the C/C++/ObjC codebase. It was not automatically
>> generated by Cython and it's not that hard to read. There's almost
>> certainly a C/C++/ObjC expert around to help out. There's almost
>> certainly Cython experts to help out, too. There is almost certainly
>> *not* an expert in Cython-generated C code that is hard to read.
>>
> There doesn't need to be.
>
>> I vote raw Python/C API. Managing reference counters is not the
>> mundane task pythonistas make it out to be, in my opinion. If you know
>> ObjC, you've had to do your own reference counting. If you know C,
>> you've had to do your own memory management. If you know C++, you've
>> had to do your own new/delete (or destructor) management. I agree not
>> having to worry about reference counting is nice positive, but I don't
>> think it outweighs the negatives.
> You have completely misrepresented the negatives.
>
>> It seems to me that Cython is a 'middle-man' tool, with the added
>> downside of hard-to-maintain under-code.
>>
> Please, if you don't use Cython yourself, and therefore don't know it
> well, refrain from these sorts of criticisms. In normal cython use, one
> *never* modifies the code it generates. In developing with cython, one
> *might* read this code to find out what is going on, and especially to
> find out whether one inadvertently triggered a call to the python API by
> forgetting to declare a variable, for example. This is pretty easy,
> because the comments in the generated code show exactly which source
> line has generated each chunk of generated code. Context is included.
> It is very nicely done.
>
> Eric
>
> ------------------------------------------------------------------------------
> 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

I think this has been a very helpful and useful discussion.
I'm going to attempt to summarize this discussion and propose some ways 
forward here.
The impetus for this discussion is that PyCXX seems to be not adequately 
maintained. It is difficult to build matplotlib with "vanilla" PyCXX in 
certain configurations. (This history sort of predates this thread).
So we have some options:
1) One way forward is to offer to take ownership of the PyCXX project. 
(I'm not using the "f" word here... I'd much prefer to just become more 
involved upstream somehow). I don't think this would be considerable 
additional work, as most of that work has been done in matplotlib for 
some time anyway. To the extent that it needs new features, it would be 
killer to add support for Numpy so Numpy no longer required manual 
reference counting. I had initially dismissed this approach, as I seem 
to be in the minority in liking PyCXX -- I happen to think it's 
fundamentally an extremely good approach to the problem: it helps with 
reference counting errors, but otherwise mostly stays out of the way. 
But I'd like to remove any one person as a bottleneck by choosing 
something that's more preferred all around.
2) Move to a different wrapping mechanism of some sort. While Cython is 
the clear choice for a third-party Python/C wrapping tool, it seems to 
be polarizing. (I won't attempt to repeat or summarize, but I think 
good points have been made on either side of the argument). I think 
it's ok to allow Cython to be used in matplotlib, given that we include 
both the Cython source and the generated C in the source repository such 
that matplotlib can be built without Cython installed. There are many 
other projects doing this that can provide best practices for us. I 
don't think, however, that we can or should require that all wrapping is 
done with Cython. I think we should allow raw Python/C API where it is 
most appropriate (and that is mainly in the case of wrapping third-party 
libraries, such as the png module and the macosx module which is already 
raw Python/C API). What I wouldn't want to see is the use of more than 
one wrapping tool, if only for reasons of proliferation of 
dependencies. (I count the Python/C API as "free" since it's always 
available anyway). I haven't seen in this discussion anyone really 
pushing for any of the alternatives (SWIG, Boost.Python, etc.) in any event.
Note also, the goal is to deal with the PyCXX "problem", not rewrite 
large chunks of our existing and well-tested C/C++ code base in Cython, 
unless someone sees a real clear benefit to doing that for a particular 
module and is highly motivated to do the work. This is primarily about 
refactoring the code so that the interface layer between Python and C is 
separated and then replaced with either Cython or raw Python/C API using 
the most appropriate tool for the job.
3) Any other options...?
Cheers,
Mike
On 12/04/2012 05:33 PM, Eric Firing wrote:
> On 2012年12月04日 12:07 PM, Damon McDougall wrote:
>> On Mon, Dec 3, 2012 at 12:12 PM, Chris Barker - NOAA Federal
>> <chr...@no...> wrote:
>>> generated code is ugly and hard to maintain, it is not designed to be
>>> human-readable, and we wouldn't get the advantages of bug-fixes
>>> further development in Cython.
>> As far as I'm concerned, this is an argument against Cython.
> Nonsense. It is an argument against the idea of maintaining the
> generated code directly, rather than maintaining the cython source code
> and regenerating the C code as needed. That idea never made any sense
> in the first place. I doubt that anyone follows it. Chris already
> pointed this out. Would you maintain the assembly code generated by
> your C++ compiler? Do you consider the fact that this is unreadable and
> unmaintainable a reason to avoid using that compiler, and instead to
> code directly in assembly?
>
>> I've had to touch the C/C++/ObjC codebase. It was not automatically
>> generated by Cython and it's not that hard to read. There's almost
>> certainly a C/C++/ObjC expert around to help out. There's almost
>> certainly Cython experts to help out, too. There is almost certainly
>> *not* an expert in Cython-generated C code that is hard to read.
>>
> There doesn't need to be.
>
>> I vote raw Python/C API. Managing reference counters is not the
>> mundane task pythonistas make it out to be, in my opinion. If you know
>> ObjC, you've had to do your own reference counting. If you know C,
>> you've had to do your own memory management. If you know C++, you've
>> had to do your own new/delete (or destructor) management. I agree not
>> having to worry about reference counting is nice positive, but I don't
>> think it outweighs the negatives.
> You have completely misrepresented the negatives.
>
>> It seems to me that Cython is a 'middle-man' tool, with the added
>> downside of hard-to-maintain under-code.
>>
> Please, if you don't use Cython yourself, and therefore don't know it
> well, refrain from these sorts of criticisms. In normal cython use, one
> *never* modifies the code it generates. In developing with cython, one
> *might* read this code to find out what is going on, and especially to
> find out whether one inadvertently triggered a call to the python API by
> forgetting to declare a variable, for example. This is pretty easy,
> because the comments in the generated code show exactly which source
> line has generated each chunk of generated code. Context is included.
> It is very nicely done.
>
> Eric
>
> ------------------------------------------------------------------------------
> 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 Wed, Dec 5, 2012 at 1:52 PM, Nathaniel Smith <nj...@po...> wrote:
> If you're defining your own warning class, you might consider using
> FutureWarning instead of UserWarning.
>
> We had a discussion about this issue for numpy recently:
> http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062460.html
> What we eventually ended up with:
> http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062468.html
Thanks for the pointers, Nathaniel. Though I think I disagree with
continuing to use DeprecationWarnings for features that will go away
and just break code - shouldn't users be given ample opportunity of
coming changes without having to find out by having their code break
at a future release?
Robert Kern wrote:
> Using FutureWarning for deprecated functions (i.e. functions that will
> disappear in future releases) is an abuse of the semantics.
> FutureWarning is for things like the numpy.histogram() changes from a
> few years ago: changes in default arguments that will change the
> semantics of a given function call. Some of our DeprecationWarnings
> possibly should be FutureWarnings, but most shouldn't I don't think.
then Nathaniel summarized:
> If a function or similar will just disappear in a future release,
> causing obvious failures in any code that depends on it, then
> DeprecationWarning is fine. People's code will unexpectedly break from
> time to time, but in safe ways, and anyway downgrading is easy.
> - Otherwise FutureWarning is preferred
And most of our DeprecationWarnings *are* about code that will just
disappear in future releases.
--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7>

On Wed, Dec 5, 2012 at 9:45 PM, Paul Ivanov <piv...@gm...> wrote:
> Hey everyone,
>
> In adding a deprecation warning in this pull request [1], Damon and I
> learned that DeprecationWarnings are ignored by default in Python 2.7
>
> This is rather unfortunate, and I outlined possible workarounds that I
> see in a commend on that PR [2].
>
> In trying to rectify this situation, I have created a
> MatplotlibDeperecationWarning class that inherits from UserWarning,
> which is *not* ignored by default. [3]
>
> 1. https://github.com/matplotlib/matplotlib/pull/1535
> 2. https://github.com/matplotlib/matplotlib/pull/1535#issuecomment-11061572
> 3. https://github.com/matplotlib/matplotlib/pull/1565
If you're defining your own warning class, you might consider using
FutureWarning instead of UserWarning.
We had a discussion about this issue for numpy recently:
 http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062460.html
What we eventually ended up with:
 http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062468.html
-n