matplotlib-devel Mailing List for matplotlib

> 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