matplotlib-devel Mailing List for matplotlib (Page 3)

As pointed out in #1650, we have a bug on Python 3.x handling file-like 
objects that are UNIX FILEs, but not actual filesystem files, such as 
the sockets used for a urllib HTTP request.
https://github.com/matplotlib/matplotlib/pull/1650
As Christoph helpfully points out, Numpy has already solved this problem 
(since 1.5.0), so it would be easiest to just use their solution.
For 1.2.x, I think we shouldn't update the Numpy requirement (which is 
currently 1.4) -- there, I'll have to port Numpy's compatibility 
functions to our code base. But for master, I'd rather just use Numpy's 
stuff so all of the intricacies of this are handled in one place.
(And as a detail, it isn't until Numpy 1.7 that a "CloseFile" function 
is provided, so even on master, we're stuck copying some code over).
Any objections?
Mike

On 01/10/2013 05:19 AM, Phil Elson wrote:
> I agree with getting going on these two. My preference is for the 
> mandrill image, but the truth is, I don't have a problem with what is 
> already there... so any of the following outcomes would be fine with me:
>
> 1. We merge mandrill & close #1599
> 2. We merge Ada & close #1581
> 3. We close #1581 & #1599 and keep Lena
>
> On the front of stacking of pull requests - I agree we have a big 
> problem. Would it be sensible to arrange a "pull request week" in the 
> next month or so, where as a development team we seriously focus on 
> closing down as many of the pull requests as possible?
>
That's a good idea, assuming we can all carve out time at the same time 
-- personally, I tend to get pulled away from matplotlib for other 
projects on a semi-random and semi-urgent basis, so it's not always easy 
to commit to things. Alternatively, maybe we could divide the open PRs 
into numerical ranges amongst some volunteers, who could triage and 
assign them to the attention of the appropriate experts?
Mike

I agree with getting going on these two. My preference is for the mandrill
image, but the truth is, I don't have a problem with what is already
there... so any of the following outcomes would be fine with me:
 1. We merge mandrill & close #1599
 2. We merge Ada & close #1581
 3. We close #1581 & #1599 and keep Lena
On the front of stacking of pull requests - I agree we have a big problem.
Would it be sensible to arrange a "pull request week" in the next month or
so, where as a development team we seriously focus on closing down as many
of the pull requests as possible?
On 10 January 2013 06:07, Eric Firing <ef...@ha...> wrote:
> We have too many pull requests stacking up. As an easy way to deal with
> two of them, does anyone strenuously object to merging #1599 and closing
> #1581? There are no comments on #1599.
>
> Eric
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

We have too many pull requests stacking up. As an easy way to deal with 
two of them, does anyone strenuously object to merging #1599 and closing 
#1581? There are no comments on #1599.
Eric

On 01/09/2013 12:20 PM, Nelle Varoquaux wrote:
> Hi all,
>
> A while back, Mike drafted a MEP to modernize the documentation:
>
> https://github.com/matplotlib/matplotlib/wiki/Mep10
>
> The main idea behind this MEP is to use the full potential of new 
> tools and conventions available for sphinx, to make the documentation 
> more readable, maintainable and consistent over the codebase. The main 
> proposed changes are the following:
>
> - follow the numpy docstring format, which is widely adopted among 
> scientific python projects (numpy, scipy, scikit-learn, scikit-image, 
> etc).
> - use the autodoc_docstring_signature of sphinx 1.1, which allow to 
> have the explicit function signature instead of the python one in the 
> generated documentation (args* and **kwargs are replaced by the 
> explicits arguments)
> - replace the duplication of the documentation (by concatenating 
> docstrings) by explicits references. This will shorten the docstrings.
> - use the autosummary extension of sphinx (sphinx aggregates small 
> classes on one page, while classes with many methods such as xes.axes 
> have one page dedicated to them)
My suggestion is actually that large classes (like Axes) would be broken 
up to multiple pages (one per method). Smaller classes can remain on 
the same page. Sphinx doesn't do any automatic determination here (as 
far as I know), but we can decide how to organize it on a class-by-class 
basis.
> - examples should link to relevant documentation
This dovetails nicely with Tony Yu's reorganization of the examples.
>
> The implementation is going to be long and tedious: Mike has separated 
> it 5 steps, that can be done independently from one another.
> If this MEP has been accepted, I can start implementing it (with step 1).
When I initially brought this MEP to the mailing list (as now), the only 
controversy was surrounding the function signatures. I think we can 
proceed with the plan to move function signatures to the top of the 
docstring for now (this is reasonably easy, since they're in the 
docstrings now, just not in a format that Sphinx can readily use). If a 
proposal is made that allows us to use **kwargs less in the first place, 
that can be done independently of the docstring changes. (Worst case, 
we end up removing the signatures from the docstrings later). But I 
haven't found a solution to the **kwargs problem that addresses the need 
to extend many disparate methods simultaneously in the future.
We can wait a little to see if there are further comments, but I think 
there's probably little major controversy over the rest of the MEP.
Mike
>
> Thanks,
> N
>
>
>
> ------------------------------------------------------------------------------
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE 49ドル.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 01/09/2013 12:43 PM, Todd wrote:
> On Wed, Jan 9, 2013 at 6:20 PM, Nelle Varoquaux 
> <nel...@gm... <mailto:nel...@gm...>> wrote:
>
> - use the autodoc_docstring_signature of sphinx 1.1, which allow
> to have the explicit function signature instead of the python one
> in the generated documentation (args* and **kwargs are replaced by
> the explicits arguments)
>
>
> If you have to manually write out the function signature anyway, 
> might this be an opportunity to review whether the use of *args and 
> **kwargs is really necessary on a case-by-case basis? I would think 
> from a code clarity and maintenance standpoint minimizing the use of 
> *args and **kwargs would be beneficial.
This approach is very useful for adding new features across many 
methods. For example, the artist properties can be extended to support, 
for example, gradient fills, without updating all of the many plotting 
methods that support filled objects. I think this is an incredibly 
powerful feature to have, and now that Sphinx and IPython both support 
extracting the signature from the docstring when present, the downsides 
are rather minor.
Mike

On Wed, Jan 9, 2013 at 6:20 PM, Nelle Varoquaux
<nel...@gm...>wrote:
>
> - use the autodoc_docstring_signature of sphinx 1.1, which allow to have
> the explicit function signature instead of the python one in the generated
> documentation (args* and **kwargs are replaced by the explicits arguments)
>
>
If you have to manually write out the function signature anyway, might
this be an opportunity to review whether the use of *args and **kwargs is
really necessary on a case-by-case basis? I would think from a code
clarity and maintenance standpoint minimizing the use of *args and **kwargs
would be beneficial.

Hi all,
A while back, Mike drafted a MEP to modernize the documentation:
https://github.com/matplotlib/matplotlib/wiki/Mep10
The main idea behind this MEP is to use the full potential of new tools and
conventions available for sphinx, to make the documentation more readable,
maintainable and consistent over the codebase. The main proposed changes
are the following:
- follow the numpy docstring format, which is widely adopted among
scientific python projects (numpy, scipy, scikit-learn, scikit-image, etc).
- use the autodoc_docstring_signature of sphinx 1.1, which allow to have
the explicit function signature instead of the python one in the generated
documentation (args* and **kwargs are replaced by the explicits arguments)
- replace the duplication of the documentation (by concatenating docstrings)
by explicits references. This will shorten the docstrings.
- use the autosummary extension of sphinx (sphinx aggregates small classes
on one page, while classes with many methods such as Axes.axes have one
page dedicated to them)
- examples should link to relevant documentation
The implementation is going to be long and tedious: Mike has separated it 5
steps, that can be done independently from one another.
If this MEP has been accepted, I can start implementing it (with step 1).
Thanks,
N

>
>
> I can work on that and submit a PR.
>
I've submitted a PR (this is Work In Progress):
https://github.com/matplotlib/matplotlib/pull/1647
I think ``get_sample_data`` should be moved to a public, documented module,
as, unlike other methods from the cbook module, it is meant for public use.
>
> >
> > Cheers,
> > Mike
> >
> >
> >>
> >> Thanks,
> >> N
> >>
> >>> Mike
> >>>
> >>>
> >>> On 01/07/2013 10:24 AM, Nelle Varoquaux wrote:
> >>>>
> >>>> Hello everyone,
> >>>>
> >>>> I was recently looking at the cbook module, and I was wondering
> >>>> whether this module was public or not. I think there are several
> >>>> unused method in it, such as ``unmasked_index_ranges``. If this isn't
> >>>> public, it may be worth cleaning the module a bit and removing the
> >>>> unused method.
> >>>>
> >>>> Cheers,
> >>>> Nelle
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> >>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
> current
> >>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> >>>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
> >>>> http://p.sf.net/sfu/learnmore_122412
> >>>> _______________________________________________
> >>>> Matplotlib-devel mailing list
> >>>> Mat...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> >>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> >>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
> >>> http://p.sf.net/sfu/learnmore_122412
> >>> _______________________________________________
> >>> Matplotlib-devel mailing list
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
>

> One way to handle this might be to
>
> a) create a new module "_cbook.py" for internal use.
> b) move everything used internally into there
> c) in cbook.py, put "from _cbook import *" and include all of these other
> functions in there
> d) emit a MatplotlibDeprecationWarning at the top level of cbook.py so
> there's a deprecation warning about the entire module.
>
> I'm not sure this is the best approach, but it's an easy way to deprecate a
> lot of things at once. Comments from other are appreciated.
I think it is going to be slightly more complicated than that, as
there are method that are meant for public use (such as
get_sample_data).
I think indeed it would be nice to deprecate most of the methods that
aren't use in matplotlib, and make private the ones that aren't useful
to users (that would make refactoring easier), but that needs to be
done cases by cases.
I can work on that and submit a PR.
>
> Cheers,
> Mike
>
>
>>
>> Thanks,
>> N
>>
>>> Mike
>>>
>>>
>>> On 01/07/2013 10:24 AM, Nelle Varoquaux wrote:
>>>>
>>>> Hello everyone,
>>>>
>>>> I was recently looking at the cbook module, and I was wondering
>>>> whether this module was public or not. I think there are several
>>>> unused method in it, such as ``unmasked_index_ranges``. If this isn't
>>>> public, it may be worth cleaning the module a bit and removing the
>>>> unused method.
>>>>
>>>> Cheers,
>>>> Nelle
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
>>>> http://p.sf.net/sfu/learnmore_122412
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
>>> http://p.sf.net/sfu/learnmore_122412
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

For oscopy I chose to use autotools with python stuff with the approach
"./configure && make && make install".
Probably I was not able to find The Good Tutorial/Documentation but I
found the learning curve very steep. And today I'm still trying to figure
out the interaction with i18n. Comparing with distutils, my understanding
is that when installing on a new machine are needed a lot of additional
packages (at least autotool suite...) with significantly increase the
complexity of first install process. I would not recommend to switch to
autotools for a python project.
Arnaud.
--
Oscopy - An interactive viewer and post-processor for electrical
simulation results http://oscopy.org
On Tue, January 8, 2013 02:50, Michiel de Hoon wrote:
> If we use autoconf for matplotlib, we may end up using a different
compiler (or compiler options) than what was used to compile Python
itself. This can lead to incompatibilities that will be very hard to
figure out. As far as I understand, using setup.py by default uses the
same compiler and appropriate compiler/linker options as was used for
Python itself.
>
> Best,
> -Michiel.
>
> --- On Mon, 1/7/13, Benjamin Root <ben...@ou...> wrote:
>
> From: Benjamin Root <ben...@ou...>
> Subject: Re: [matplotlib-devel] autoconf+python
> To: "Thomas Kluyver" <th...@kl...>
> Cc: "matplotlib development list"
<mat...@li...> Date: Monday, January 7, 2013,
12:24 PM
>
>
>
> On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl...>
wrote:
>
>
> On 7 January 2013 16:57, Benjamin Root <ben...@ou...> wrote:
>
>
>
>
> I was just reading some comments from Richard Stallman on ./ when I
noticed that he pointed out a useful autoconf feature that was added
somewhat recently. Essentially, this feature would allow one to do a
build/install of a python module using the "./configure; make install"
approach, if one chooses. Maybe it should be something to consider
adding to our build system?
>
>
>
>
> My 2 cents: I took over the maintenance of a Python project built by
autotools. The build system felt more complex than the actual
application - a fantastic world of .am files generating .in files
generating Makefiles, which themselves were packed with abstractions. I
had little idea how to change anything in the build process, and before
long I ri

If we use autoconf for matplotlib, we may end up using a different compiler (or compiler options) than what was used to compile Python itself. This can lead to incompatibilities that will be very hard to figure out. As far as I understand, using setup.py by default uses the same compiler and appropriate compiler/linker options as was used for Python itself.
Best,
-Michiel.
--- On Mon, 1/7/13, Benjamin Root <ben...@ou...> wrote:
From: Benjamin Root <ben...@ou...>
Subject: Re: [matplotlib-devel] autoconf+python
To: "Thomas Kluyver" <th...@kl...>
Cc: "matplotlib development list" <mat...@li...>
Date: Monday, January 7, 2013, 12:24 PM
On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl...> wrote:
On 7 January 2013 16:57, Benjamin Root <ben...@ou...> wrote:
I was just reading some comments from Richard Stallman on ./ when I noticed that he pointed out a useful autoconf feature that was added somewhat recently. Essentially, this feature would allow one to do a build/install of a python module using the "./configure; make install" approach, if one chooses. Maybe it should be something to consider adding to our build system?
My 2 cents: I took over the maintenance of a Python project built by autotools. The build system felt more complex than the actual application - a fantastic world of .am files generating .in files generating Makefiles, which themselves were packed with abstractions. I had little idea how to change anything in the build process, and before long I ripped it out in favour of setup.py, despite all distutils' flaws.
I'm sure that's more a question of my experience than of autotools, but I'd think twice before adding it to a project.
Best wishes,
Thomas
That's a very good point. I certainly don't want to add significant complexity to our build system. We certainly have enough of it as-is. I was hoping that there was a way to complement our setup.py approach. In other words, "python setup.py install" would be our primary means of build/install, while allowing for "make install" as an alternative. I have yet to actually look into how this current autoconf feature would work and if that is even possible.
Ben Root
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
-----Inline Attachment Follows-----
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 01/07/2013 12:38 PM, Eric Firing wrote:
> On 2013年01月07日 7:29 AM, Michael Droettboom wrote:
>> I, also, am not too much up on the details --- but I think if it's
>> possible for "make install" to just call "python setup.py install" under
>> the hood, I'd have no objections.
> I think I would even object to that. What would be the point of it?
> What problem would it solve?
>
Very little point, admittedly. But I still encounter sysadmins who 
insist on "./configure; make; make install" to work sometimes.
Mike

On Po, 2013年01月07日 at 07:38 -1000, Eric Firing wrote:
> On 2013年01月07日 7:29 AM, Michael Droettboom wrote:
> > I, also, am not too much up on the details --- but I think if it's
> > possible for "make install" to just call "python setup.py install" under
> > the hood, I'd have no objections.
> 
> I think I would even object to that. What would be the point of it? 
> What problem would it solve?
> 
> Eric
There is one thing autotools are good at: Very easy cross-compilation
for end-users and pleasant handling of the C/C++ stuff (conditional
compilation, custom flags specified on command-line, lots of checks you
can perform before compilation, integrated testing framework etc.)
The only pitfall is that writing autotools stuff without knowing best
practices or without having full understanding of what you are doing is
going to result in endless bugreports you won't know how to solve.
If matplotlib relies heavily on C libraries, it might be beneficial,
otherwise it is probably not worth the effort for Python projects.
Matej

On 2013年01月07日 7:29 AM, Michael Droettboom wrote:
> I, also, am not too much up on the details --- but I think if it's
> possible for "make install" to just call "python setup.py install" under
> the hood, I'd have no objections.
I think I would even object to that. What would be the point of it? 
What problem would it solve?
Eric

On 01/07/2013 12:24 PM, Benjamin Root wrote:
>
>
> On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl... 
> <mailto:th...@kl...>> wrote:
>
> On 7 January 2013 16:57, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
> I was just reading some comments from Richard Stallman on ./
> when I noticed that he pointed out a useful autoconf feature
> that was added somewhat recently. Essentially, this feature
> would allow one to do a build/install of a python module using
> the "./configure; make install" approach, if one chooses. 
> Maybe it should be something to consider adding to our build
> system?
>
>
> My 2 cents: I took over the maintenance of a Python project built
> by autotools. The build system felt more complex than the actual
> application - a fantastic world of .am files generating .in files
> generating Makefiles, which themselves were packed with
> abstractions. I had little idea how to change anything in the
> build process, and before long I ripped it out in favour of
> setup.py, despite all distutils' flaws.
>
> I'm sure that's more a question of my experience than of
> autotools, but I'd think twice before adding it to a project.
>
> Best wishes,
> Thomas
>
>
> That's a very good point. I certainly don't want to add significant 
> complexity to our build system. We certainly have enough of it 
> as-is. I was hoping that there was a way to complement our setup.py 
> approach. In other words, "python setup.py install" would be our 
> primary means of build/install, while allowing for "make install" as 
> an alternative. I have yet to actually look into how this current 
> autoconf feature would work and if that is even possible.
I, also, am not too much up on the details --- but I think if it's 
possible for "make install" to just call "python setup.py install" under 
the hood, I'd have no objections. What I'd be wary of would be 
maintaining multiple install scripts. It's hard enough keeping one up 
to date with all of the various platforms and configurations we 
support. I'd be happy to replace that one with something that's clearly 
superior, however, but distutils, bad as it is, seems to be "good enough".
Mike

On 2013年01月07日 7:24 AM, Benjamin Root wrote:
>
>
> On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl...
> <mailto:th...@kl...>> wrote:
>
> On 7 January 2013 16:57, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
> I was just reading some comments from Richard Stallman on ./
> when I noticed that he pointed out a useful autoconf feature
> that was added somewhat recently. Essentially, this feature
> would allow one to do a build/install of a python module using
> the "./configure; make install" approach, if one chooses. Maybe
> it should be something to consider adding to our build system?
>
>
> My 2 cents: I took over the maintenance of a Python project built by
> autotools. The build system felt more complex than the actual
> application - a fantastic world of .am files generating .in files
> generating Makefiles, which themselves were packed with
> abstractions. I had little idea how to change anything in the build
> process, and before long I ripped it out in favour of setup.py,
> despite all distutils' flaws.
>
> I'm sure that's more a question of my experience than of autotools,
> but I'd think twice before adding it to a project.
>
> Best wishes,
> Thomas
>
>
> That's a very good point. I certainly don't want to add significant
> complexity to our build system. We certainly have enough of it as-is.
> I was hoping that there was a way to complement our setup.py approach.
> In other words, "python setup.py install" would be our primary means of
> build/install, while allowing for "make install" as an alternative. I
> have yet to actually look into how this current autoconf feature would
> work and if that is even possible.
Ben,
What specific problem with our present system would you be trying to 
solve? I'm with Thomas on this--and there's a reason why people keep 
trying to develop new build systems, like cmake, scons, and waf, instead 
of being content with autotools.
Eric
>
> Ben Root

On 01/07/2013 11:05 AM, Nelle Varoquaux wrote:
> On 7 January 2013 16:38, Michael Droettboom <md...@st...> wrote:
>> I know there's a lot of code in the wild that treats cbook as public and
>> would probably be affected by it going away. However, there hasn't been
>> much care taken within that module as to what we want to support
>> publicly and what would be better left as private. Many things in it,
>> of course, are imported to the top-level of the matplotlib package, and
>> those are quite strongly public, I would say, but we probably have to do
>> these things on a case-by-case basis. I think the best approach is to
>> probably deprecate now and remove later -- though there may be some
>> things in there that we want to keep even if they aren't used internally
>> (but let's add some tests in the latter case). Do you have a complete
>> list of everything in cbook that isn't used by matplotlib itself?
> This is a list I quickly built: I have no certainty that it is correct
> nor complete:
>
> book's unused functions and classes in matplotlib:
>
> unmasked_index_ranges
> tostr (note that there is a method called tostr in mlab)
> todatetime
> todate
> tofloat
> toint
> _BoundMethodProxy
> TimeOut
> Idler
> Scheduler (is used by TimeOut and Idler)
> uniquer
> Sorter
> Xlator
> soundex
> Null
> dict_delall
> RingBuffer
> wrap (unsure)
> pieces
> alltrue
> allpairs
> finddir
> reverse_dict
> MemoryMonitor
> unmasked_index_ranges
>
> functions that are redefined elsewhere:
> is_math_text (in the text module)
>
> I can have a closer look and deprecate things that aren't used
> anywhere and don't seem very useful to anyone.
That seems like a reasonable approach.
One way to handle this might be to
a) create a new module "_cbook.py" for internal use.
b) move everything used internally into there
c) in cbook.py, put "from _cbook import *" and include all of these 
other functions in there
d) emit a MatplotlibDeprecationWarning at the top level of cbook.py so 
there's a deprecation warning about the entire module.
I'm not sure this is the best approach, but it's an easy way to 
deprecate a lot of things at once. Comments from other are appreciated.
Cheers,
Mike
>
> Thanks,
> N
>
>> Mike
>>
>>
>> On 01/07/2013 10:24 AM, Nelle Varoquaux wrote:
>>> Hello everyone,
>>>
>>> I was recently looking at the cbook module, and I was wondering
>>> whether this module was public or not. I think there are several
>>> unused method in it, such as ``unmasked_index_ranges``. If this isn't
>>> public, it may be worth cleaning the module a bit and removing the
>>> unused method.
>>>
>>> Cheers,
>>> Nelle
>>>
>>> ------------------------------------------------------------------------------
>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
>>> http://p.sf.net/sfu/learnmore_122412
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122412
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Jan 7, 2013 at 12:11 PM, Thomas Kluyver <th...@kl...>wrote:
> On 7 January 2013 16:57, Benjamin Root <ben...@ou...> wrote:
>
>> I was just reading some comments from Richard Stallman on ./ when I
>> noticed that he pointed out a useful autoconf feature that was added
>> somewhat recently. Essentially, this feature would allow one to do a
>> build/install of a python module using the "./configure; make install"
>> approach, if one chooses. Maybe it should be something to consider adding
>> to our build system?
>
>
> My 2 cents: I took over the maintenance of a Python project built by
> autotools. The build system felt more complex than the actual application -
> a fantastic world of .am files generating .in files generating Makefiles,
> which themselves were packed with abstractions. I had little idea how to
> change anything in the build process, and before long I ripped it out in
> favour of setup.py, despite all distutils' flaws.
>
> I'm sure that's more a question of my experience than of autotools, but
> I'd think twice before adding it to a project.
>
> Best wishes,
> Thomas
>
>
That's a very good point. I certainly don't want to add significant
complexity to our build system. We certainly have enough of it as-is. I
was hoping that there was a way to complement our setup.py approach. In
other words, "python setup.py install" would be our primary means of
build/install, while allowing for "make install" as an alternative. I have
yet to actually look into how this current autoconf feature would work and
if that is even possible.
Ben Root

On 7 January 2013 16:57, Benjamin Root <ben...@ou...> wrote:
> I was just reading some comments from Richard Stallman on ./ when I
> noticed that he pointed out a useful autoconf feature that was added
> somewhat recently. Essentially, this feature would allow one to do a
> build/install of a python module using the "./configure; make install"
> approach, if one chooses. Maybe it should be something to consider adding
> to our build system?
My 2 cents: I took over the maintenance of a Python project built by
autotools. The build system felt more complex than the actual application -
a fantastic world of .am files generating .in files generating Makefiles,
which themselves were packed with abstractions. I had little idea how to
change anything in the build process, and before long I ripped it out in
favour of setup.py, despite all distutils' flaws.
I'm sure that's more a question of my experience than of autotools, but I'd
think twice before adding it to a project.
Best wishes,
Thomas

I was just reading some comments from Richard Stallman on ./ when I noticed
that he pointed out a useful autoconf feature that was added somewhat
recently. Essentially, this feature would allow one to do a build/install
of a python module using the "./configure; make install" approach, if one
chooses. Maybe it should be something to consider adding to our build
system?
http://www.gnu.org/software/automake/manual/html_node/Python.html
Cheers!
Ben Root

On 7 January 2013 16:38, Michael Droettboom <md...@st...> wrote:
> I know there's a lot of code in the wild that treats cbook as public and
> would probably be affected by it going away. However, there hasn't been
> much care taken within that module as to what we want to support
> publicly and what would be better left as private. Many things in it,
> of course, are imported to the top-level of the matplotlib package, and
> those are quite strongly public, I would say, but we probably have to do
> these things on a case-by-case basis. I think the best approach is to
> probably deprecate now and remove later -- though there may be some
> things in there that we want to keep even if they aren't used internally
> (but let's add some tests in the latter case). Do you have a complete
> list of everything in cbook that isn't used by matplotlib itself?
This is a list I quickly built: I have no certainty that it is correct
nor complete:
book's unused functions and classes in matplotlib:
unmasked_index_ranges
tostr (note that there is a method called tostr in mlab)
todatetime
todate
tofloat
toint
_BoundMethodProxy
TimeOut
Idler
Scheduler (is used by TimeOut and Idler)
uniquer
Sorter
Xlator
soundex
Null
dict_delall
RingBuffer
wrap (unsure)
pieces
alltrue
allpairs
finddir
reverse_dict
MemoryMonitor
unmasked_index_ranges
functions that are redefined elsewhere:
is_math_text (in the text module)
I can have a closer look and deprecate things that aren't used
anywhere and don't seem very useful to anyone.
Thanks,
N
>
> Mike
>
>
> On 01/07/2013 10:24 AM, Nelle Varoquaux wrote:
>> Hello everyone,
>>
>> I was recently looking at the cbook module, and I was wondering
>> whether this module was public or not. I think there are several
>> unused method in it, such as ``unmasked_index_ranges``. If this isn't
>> public, it may be worth cleaning the module a bit and removing the
>> unused method.
>>
>> Cheers,
>> Nelle
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122412
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I know there's a lot of code in the wild that treats cbook as public and 
would probably be affected by it going away. However, there hasn't been 
much care taken within that module as to what we want to support 
publicly and what would be better left as private. Many things in it, 
of course, are imported to the top-level of the matplotlib package, and 
those are quite strongly public, I would say, but we probably have to do 
these things on a case-by-case basis. I think the best approach is to 
probably deprecate now and remove later -- though there may be some 
things in there that we want to keep even if they aren't used internally 
(but let's add some tests in the latter case). Do you have a complete 
list of everything in cbook that isn't used by matplotlib itself?
Mike
On 01/07/2013 10:24 AM, Nelle Varoquaux wrote:
> Hello everyone,
>
> I was recently looking at the cbook module, and I was wondering
> whether this module was public or not. I think there are several
> unused method in it, such as ``unmasked_index_ranges``. If this isn't
> public, it may be worth cleaning the module a bit and removing the
> unused method.
>
> Cheers,
> Nelle
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE 99ドル.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Yes, it is public, but it is geared for internal use.

Hello everyone,
I was recently looking at the cbook module, and I was wondering
whether this module was public or not. I think there are several
unused method in it, such as ``unmasked_index_ranges``. If this isn't
public, it may be worth cleaning the module a bit and removing the
unused method.
Cheers,
Nelle