On Wed, Jun 3, 2015 at 3:46 AM, Nathaniel Smith wrote:
> Hi all,
>
> As was hinted at in a previous thread, Stéfan van der Walt and I have
> been using some Fancy Color Technology to attempt to design a new
> colormap intended to become matplotlib's new default. (Down with jet!)
>
> Unfortunately
On Feb 19, 2015 1:39 AM, "Nathaniel Smith" wrote:
>
> On Feb 16, 2015 3:39 PM, "Eric Firing" wrote:
> >
> > On 2015/02/16 1:29 PM, Michael Waskom wrote:
> >
> > > Nathaniel's January 9 message in that thread (can't figure out how to
> > > link to it in the archives) had a suggestion that I though
he goal of pulling pyplot out of backend_bases is exactly that, to be
able to do everything using the OO interface in a convenient way.
>
> Tom
>
> On Sun Feb 08 2015 at 4:50:51 PM Todd wrote:
>>
>>
>> On Feb 8, 2015 1:13 AM, "Thomas Caswell" wrote:
>> >
On Feb 8, 2015 1:13 AM, "Thomas Caswell" wrote:
>
> Hey all,
>
> To start with, the 2.0 release is pending a choice of new default color
map. I think that when we pick that we should cut 2.0 off of the last
release and then the next minor release turns into 2.1. If we want to do
other breaking c
On Nov 26, 2014 10:04 PM, "Nathaniel Smith" wrote:
>
> On Wed, Nov 26, 2014 at 9:30 AM, Todd wrote:
> > On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith wrote:
> >>
> >> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>
On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith wrote:
> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> appear to be based on any real theory about visualization -- it's just
> the corners of the RGB color cube, which is a highly perceptually
> non-uniform space. The re
I think using native icons would be the best scenario, at least whet the
backend and platform support it.
On Nov 22, 2014 9:08 AM, "Nicolas P. Rougier"
wrote:
>
> I would be also quite interested in having better defaults. My list of
> "complains" are:
>
> * Easy way to get only two lines for ax
On Nov 1, 2014 4:49 PM, "Thomas Caswell" wrote:
>
> Does anyone protest to removing all of the branches from the main repo
except:
>
> - master
> - v1.4.x
> - v1.4.2-doc
>
> Having old branches around can lead to confusion (see
https://github.com/matplotlib/matplotlib/pull/3748#issuecomment-613
On Sun, Sep 28, 2014 at 7:52 PM, Eric Firing wrote:
> Regarding Matlab: it is justly popular for many reasons. It is
> relatively easy to learn both by design and because of its consistent
> high-quality documentation. Matplotlib's success has resulted in large
> measure from its pyplot layer, w
I would suggest create a new branch, though. You can create a new branch
from the old one, then make your changes there. That way if you mess up
something you still have the original to fall back on.
On Thu, Jul 31, 2014 at 5:15 PM, Thomas Caswell wrote:
> Git lets you re-write history pretty
On Mar 6, 2014 10:24 PM, "Skip Montanaro" wrote:
>
> On Thu, Mar 6, 2014 at 3:13 PM, Nelle Varoquaux
> wrote:
> > If I need to understand what exactly os.stat returns, I just read the
> > documentation, and not rely on some possibly misleading variable
> > names.
>
> Despite our wish that it wasn
On Fri, Oct 25, 2013 at 2:34 PM, Pierre Haessig wrote:
> Hi,
>
> Le 22/10/2013 19:14, Todd a écrit :
>
> Thanks for the feedback. I agree that your documentation does make clear
>> the distinction between "phase" and "angle" and that it has a consiste
On Fri, Oct 25, 2013 at 2:57 PM, Pierre Haessig wrote:
> Hello,
>
>
> Now that that PR #2522 is merged, I don't know how much futher commenting
> is useful, but I think there are two API details that I feel could be
> better :
>
> 1) API dissymetry
>
> The new pyplot/axes API is now:
>
> * 1 fun
On Fri, Oct 25, 2013 at 3:06 PM, Pierre Haessig wrote:
> Hi,
>
> Le 21/10/2013 15:58, Todd a écrit :
>
> 2) Should there be two separate functions for these two, or just one
>>
>> function, with a switch argument `unwrap` ? (I guess it would be True by
>>
I think another problem is having pyplot and axes as dumping grounds for
all plot types. This probably made sense back when there were only a few
types of plots, but now there is a massive number of them. They all end up
in one large class with one large documentation page, making it very hard
to
I think one thing that contributes a lot to the API issues is the
inconsistency between pyplot API and the OO API. There isn't any reason
the APIs need to be so different.
To continue with this example, pyplot.subplot and Figure.add_subplot do
basically the same thing, but they have different nam
On Oct 24, 2013 8:40 PM, "Chris Barker" wrote:
>
> On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom
wrote:
> > Here are the notes with action items from the meeting:
>
> thanks for posting that. I see:
>
> pylab - should it stay or should it go?
>
> Comment from the peanut gallery:
>
> Go.
I
Here are the questions I asked during the hangouts session (paraphrased):
-
Regarding continuous integration:
Has looked into OBS? (open build server, https://build.opensuse.org/) It
can be installed on a local machine or server, suppor
Was anyone looking at the questions? I posted a bunch of questions but
nobody seemed to notice them.
On Thu, Oct 24, 2013 at 3:41 PM, Michael Droettboom wrote:
> Just a reminder, we are having a general matplotlib development hangout
> today. Everyone that responded to the Doodle poll from a
On Tue, Oct 22, 2013 at 6:06 PM, Pierre Haessig wrote:
> Hi,
>
> Le 21/10/2013 15:58, Todd a écrit :
>
> On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig > wrote:
>
>1) is the terminology "phase" vs. "angle" spectrum standardized ? I
>> mu
On Tue, Oct 22, 2013 at 5:41 PM, Pierre Haessig wrote:
> Hi,
>
> Le 22/10/2013 12:31, Todd a écrit :
> > Currently, both axes.psd and axes.csd return the same thing as
> > mlab.psd and mlab.csd, namely the spectrum and frequency points. They
> > do NOT return the l
On Sun, Oct 20, 2013 at 9:45 AM, Todd wrote:
> Hello,
>
> I submitted a pull request #2522 [1]. It includes support for more basic
> spectrum plots like magnitude and phase spectrums. These are extremely
> commonly used in signal processing, acoustics, and many other fields,
On Tue, Oct 22, 2013 at 9:30 AM, Ian Thomas wrote:
> On 22 October 2013 07:53, Todd wrote:
>
>> As of last night, I can no longer compile master. I get the following
>> error:
>>
>> building 'matplotlib.ttconv' extension
>> creating build/temp.
As of last night, I can no longer compile master. I get the following
error:
building 'matplotlib.ttconv' extension
creating build/temp.linux-x86_64-2.7/extern/ttconv
gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronou
On Mon, Oct 21, 2013 at 7:36 PM, Chris Barker wrote:
> > To expand slightly, with the current situation the onus is on us to
> ensure
> > that mpl builds OK and passes all of our tests with and without each of
> the
> > external libraries.
>
> If you only have internal libs, then there is less to
Seems like a lot of what they are doing could be upstreamed into
matplotlib. Then they could just wrap it in their own ggplot syntax. That
would improve matplotlib and simplify the maintainance for them.
On Mon, Oct 21, 2013 at 5:58 PM, Michael Droettboom wrote:
> I just learned about this t
On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig wrote:
> Hi,
>
> Le 20/10/2013 09:45, Todd a écrit :
> > I submitted a pull request #2522 [1]. It includes support for more
> > basic spectrum plots like magnitude and phase spectrums. These are
> > extremely commonl
Hello,
I submitted a pull request #2522 [1]. It includes support for more basic
spectrum plots like magnitude and phase spectrums. These are extremely
commonly used in signal processing, acoustics, and many other fields, but
are also very important for educational usage since pretty much anyone
On Oct 18, 2013 8:20 PM, "Chris Barker" wrote:
>
> Ian,
>
> > I am working on a PR to replace the use of matplotlib.delaunay with the
> > Qhull library.
>
> nice! -- ( though I sure wish Qhull did constrained delaunay...)
>
> > Installation will be similar to the existing packages LibAgg
> > and C
and poke at it. Or just point us to your git branch so we
> could check it out.
>
> Mike
>
>
> On 10/10/2013 07:33 AM, Todd wrote:
>
> I have been implementing some new plot types, with tests. This code
> passes all existing tests. I have also expanded the tests on som
I have been implementing some new plot types, with tests. This code passes
all existing tests. I have also expanded the tests on some existing plot
types and mlab functions. These tests run fine on their own.
The problem is that, when I run the code with the new tests, I get a lot of
out of mem
Hi, I am trying to make some improvements to the spectrum-related functions
in mlab (and the corresponding plotting functions).
What I am trying to do is make the functions more general, so they work
with complex spectrums, magnitude spectrums, and phase spectrums in
addition to PSDs. The problem
Currently, many of the plot types reside in axes. This makes sense from a
structural standpoint, since the plots are generally a part of an axes.
However, it makes things more difficult from a practical standpoint.
First, it means that the axes class is huge, with both core axes-related
methods an
On Feb 8, 2013 11:14 PM, "Benjamin Root" wrote:
>
> Just a crazy thought, but why are we trying to treat "title" and such as
properties? When I think of properties for matplotlib, I think of
edgecolors, fontsize, and linestyles. Why don't we solve that problem
first?
In my mind there are severa
On Fri, Feb 8, 2013 at 2:40 AM, Antony Lee wrote:
> Hi,
>
> I saw that a discussion started on transitioning to the use of properties
> instead of explicit getters and setters, which seems like a very good idea
> to me... so I thought this would be a good idea to get involved in
> matplotlib-deve
On Fri, Feb 8, 2013 at 3:38 AM, Jason Grout wrote:
> On 2/7/13 8:08 PM, Erik Bray wrote:
> > A couple easier solutions: Allow
> > the `.title` (and other such attributes) to be assigned to with a
> > (value, options) tuple where the value is the title itself, and the
> > options is a dictionary or
On Fri, Feb 8, 2013 at 10:04 AM, Antony Lee wrote:
> 2013/2/7 Erik Bray
>
>> On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee
>> wrote:
>> > Hi,
>> >
>> > I saw that a discussion started on transitioning to the use of
>> properties
>> > instead of explicit getters and setters, which seems like a very
Is there a process that someone needs to go through to get a pull request
merged into master?
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
h
On Thu, Jan 17, 2013 at 11:30 AM, Todd wrote:
> On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson wrote:
>
>> Hi Todd,
>>
>> I agree with the principle of properties - it will make much of the mpl
>> codebase (and user code) more pythonic, so thanks for proposing th
On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson wrote:
> Hi Todd,
>
> I agree with the principle of properties - it will make much of the mpl
> codebase (and user code) more pythonic, so thanks for proposing this.
>
> Would you be able to give an example of how you propo
On Wed, Jan 16, 2013 at 2:52 PM, Michael Droettboom wrote:
> This seems like a good candidate for a MEP. We'd want to take a
> graceful approach to transitioning to properties.
>
> See here for information about MEPs:
>
> https://github.com/matplotlib/matplotlib/wiki
>
> Mike
>
>
>
>
I have cre
I have created a very preliminary MEP for the possible move to properties:
https://github.com/matplotlib/matplotlib/wiki/MEP13
Please take a look at it and discuss. As I said, this is very
preliminary. Everything is subject to change.
On Wed, Jan 16, 2013 at 2:55 PM, Benjamin Root wrote:
>
> On Wed, Jan 16, 2013 at 2:42 PM, Todd wrote:
>
>> Currently matplotlib uses set_ and get_ functions for reading and writing
>> values. However, since 2.6 python supports properties, which allow access
>> to s
Currently matplotlib uses set_ and get_ functions for reading and writing
values. However, since 2.6 python supports properties, which allow access
to such values as attributes in addition to using the functions directly.
Would it be worthwhile implementing property support in matplotlib?
On Jan 16, 2013 9:30 AM, "Fernando Perez" wrote:
>
> On Wed, Jan 16, 2013 at 12:10 AM, Nelle Varoquaux
> wrote:
>
> > Last but not least, maybe we can see what numfocus has to offer.
>
> Absolutely! I'll be offline for two weeks, but others on the list can
> certainly propose this to numfocus on
On Mon, Jan 14, 2013 at 1:28 AM, Todd wrote:
> On Mon, Nov 12, 2012 at 6:35 PM, Damon McDougall <
> damon.mcdoug...@gmail.com> wrote:
>
>> On Mon, Nov 12, 2012 at 2:17 PM, Paul Ivanov
>> wrote:
>> > On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom
&g
On Mon, Nov 12, 2012 at 6:35 PM, Damon McDougall
wrote:
> On Mon, Nov 12, 2012 at 2:17 PM, Paul Ivanov wrote:
> > On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom
> wrote:
> >> On 11/11/2012 11:51 PM, Todd wrote:
> >>> Now that 1.2 is out, can we revi
On Wed, Jan 9, 2013 at 6:20 PM, Nelle Varoquaux
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 ha
On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall
wrote:
> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
> wrote:
> > On 12/14/12 10:55 AM, Nathaniel Smith wrote:
> >> sourceforge's horror of an interface.
> >
> > I'll second that. Every time I go to Sourceforge, I have to figure out
> > how in th
On Dec 14, 2012 5:59 PM, "Michael Droettboom" wrote:
>
> Github has removed the ability to host binaries. They've removed this
feature without any apparent notification except on their blog saying "it's
gone today". And the suggested alternative is to use paid services.
>
> https://github.com/bl
On Thu, Sep 27, 2012 at 8:18 PM, Todd wrote:
> On Thu, Sep 27, 2012 at 1:44 PM, Todd wrote:
>> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
>> wrote:
>>> Hi Todd,
>>>
>>> Firstly, thanks for taking the time to crystallise your thoughts in
>&g
On Mon, Oct 15, 2012 at 2:11 PM, Phil Elson wrote:
>> if we leave PEP8 out of v1.2.x, and decide that once it is released,
>> v1.2.x will be changed
>> only if critical bugs are found, requiring a v1.2.1 release
>
> I agree. I think it is important here to be very clear about what
> constitutes a
should the
GTK backends just be disabled on Python 3 builds?
Thanks for your help.
-Todd
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and
there are groups
dedicated to making it easy to install python packages on windows, I
don't see the point of going through all the trouble of making your
own version. If you really wanted to you might even be able to use
their sources to create your
On Thu, Sep 27, 2012 at 1:44 PM, Todd wrote:
> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
> wrote:
>> Hi Todd,
>>
>> Firstly, thanks for taking the time to crystallise your thoughts in
>> words first. This is one of my bad habits; I tend to rush into things.
On Thu, Sep 27, 2012 at 2:17 PM, Damon McDougall
wrote:
> On Thu, Sep 27, 2012 at 12:44 PM, Todd wrote:
>> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
>> wrote:
>>> Hi Todd,
>>>
>>> Firstly, thanks for taking the time to crystallise your thoughts
On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
wrote:
> Hi Todd,
>
> Firstly, thanks for taking the time to crystallise your thoughts in
> words first. This is one of my bad habits; I tend to rush into things.
>
> I have some feedback for you, hopefully we can all work toge
On Thu, Sep 27, 2012 at 12:58 PM, Thomas Kluyver wrote:
> On 27 September 2012 11:41, Todd wrote:
>> I would prefer to get the details worked out before I start coding
>> since there are a few different approaches. First thing is to figure
>> out a good name, I am not sure
On Wed, Sep 26, 2012 at 3:14 PM, Michael Droettboom wrote:
> On 09/26/2012 04:35 AM, Todd wrote:
>
> On Mon, Sep 24, 2012 at 3:33 PM, Todd wrote:
>>
>> I would like to add a new plot type to matplotlib. Of course I am willing
>> to implement it myself, but I
On Mon, Sep 24, 2012 at 3:33 PM, Todd wrote:
> I would like to add a new plot type to matplotlib. Of course I am willing
> to implement it myself, but I want to confirm that it is acceptable and
> iron out the implementation details and API first so there are no major
> surprises w
On Mon, Sep 24, 2012 at 3:51 PM, Nathaniel Smith wrote:
> On Mon, Sep 24, 2012 at 2:33 PM, Todd wrote:
>> This sort of plot is used ubiquitously in neuroscience. It is used to show
>> the time of discrete neural (brain cell) events (called "spikes") over time
>
I would like to add a new plot type to matplotlib. Of course I am willing
to implement it myself, but I want to confirm that it is acceptable and
iron out the implementation details and API first so there are no major
surprises when I submit it.
I tentatively am calling the plot type an "EventRas
Hi, I am interested in implementing a new plot type for matplotlib. Is
there a specific process I should go through, or is just discussing it on
the mailing list sufficient?
I see matplotlib has a MEP system similar to PEP, but there don't appear to
be that many MEPs so I don't know whether it is
hod, perhaps we would be better off with a helper
> method to create the xs and ys for fill_between
>
> xs, ys = mlab.pad_line(x, y, 0.2)
> fill_between(xs, ys)
>
> JDH
What about adding a property
On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut
wrote:
> Hi all,
>
> Is anyone interested in including the Matplotlib QtDesigner plugin
> which I wrote for Python(x,y)?
>
> The code is quite simple and hasn't evolved for a while now (3 years)
> but apparently it is still appreciated by users even
I've included this in openSUSE's matplotlib packages, it seems to work great.
-Todd
On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut
wrote:
> Hi all,
>
> Is anyone interested in including the Matplotlib QtDesigner plugin
> which I wrote for Python(x,y)?
>
> The cod
66 matches
Mail list logo
