matplotlib-devel Mailing List for matplotlib

On Wed, Jan 30, 2013 at 8:44 AM, Michael Droettboom <md...@st...> wrote:
> In discussions with Perry Greenfield at STScI, it seems we are in the
> position of being able to get some financial support to pay for a
> continuous integration system.
>
> Travis has shown itself to be rather glitchy for matplotlib. The tight
> integration with Github PRs is really convenient. However, matplotlib
> has longer test runs and more dependencies than many projects. The
> frequent false positives start to wear down at a certain point. And we
> still aren't testing everything because we can't aren't installing
> Inkscape and other things in the Travis VM.
>
> So we're looking to add another paid, hosted continuous integration
> service that will better meet our needs. A hosted service is nice
> because it's easy to give multiple developers access to the system so
> anyone can tweak it and keep it going -- the bottleneck of a single
> developer responsible for maintenance of the build machine was a problem
> years ago when we were using buildbot. This may remain "in addition to"
> rather than "instead of" Travis for some time.
>
> An obvious first choice to me is ShiningPanda, as I have experience
> using it for astropy. Jenkins (the software Shining Panda is based on),
> is a really easy-to-use system, for those not familiar with it. And we
> can store the output of the tests (i.e. the result_images) for later
> inspection. I think this feature alone is huge for matplotlib. They
> also offer Windows build slaves. There is no OS-X (probably because
> Apple licensing doesn't really allow for use in a VM), but results can
> be "published" to their Jenkins instance.
>
> Are there any other similar alternatives we should consider before we
> move forward?
>
> Mike
I think hosted infrastructure is the right choice. I was initially
going to suggest that we try and work with a bespoke solution. That
way we could roll our own build architectures.
On reflection I think the maintenance headache of managing our own
build slaves outweighs the convenience of having it hosted, as you
point out.
-- 
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

In discussions with Perry Greenfield at STScI, it seems we are in the 
position of being able to get some financial support to pay for a 
continuous integration system.
Travis has shown itself to be rather glitchy for matplotlib. The tight 
integration with Github PRs is really convenient. However, matplotlib 
has longer test runs and more dependencies than many projects. The 
frequent false positives start to wear down at a certain point. And we 
still aren't testing everything because we can't aren't installing 
Inkscape and other things in the Travis VM.
So we're looking to add another paid, hosted continuous integration 
service that will better meet our needs. A hosted service is nice 
because it's easy to give multiple developers access to the system so 
anyone can tweak it and keep it going -- the bottleneck of a single 
developer responsible for maintenance of the build machine was a problem 
years ago when we were using buildbot. This may remain "in addition to" 
rather than "instead of" Travis for some time.
An obvious first choice to me is ShiningPanda, as I have experience 
using it for astropy. Jenkins (the software Shining Panda is based on), 
is a really easy-to-use system, for those not familiar with it. And we 
can store the output of the tests (i.e. the result_images) for later 
inspection. I think this feature alone is huge for matplotlib. They 
also offer Windows build slaves. There is no OS-X (probably because 
Apple licensing doesn't really allow for use in a VM), but results can 
be "published" to their Jenkins instance.
Are there any other similar alternatives we should consider before we 
move forward?
Mike

On 28 January 2013 15:57, Michael Droettboom <md...@st...> wrote:
> Thanks. Sorry about not communicating the new dependency very well. As
> this only affects those building the docs (meaning primarily developers and
> not end-users) it wasn't given the same care.
>
That's fine. I think I did see the discussion, but I didn't pay it much
attention.
> We had had some back-and-forth about whether to include a local copy of
> numpydoc in matplotlib, but ultimately decided not to as this is generally
> not what packagers like to see. In there a way to depend on numpydoc from
> the development release in your PPA (only as a build-time dependency?)
>
If we want builds for pre-raring versions, I think the way to do it would
be to backport the numpydoc package, and put it in the PPA - it will use
packages in the same PPA to satisfy build dependencies. This is easy enough
to do if people want it, I'm just aware that each build runs for the best
part of an hour*, on two architectures times however many releases we
target. If people are actually interested in running the daily packages,
that's worth doing, but if not, I don't want to tie up Launchpad's build
farm. My own use was the Python 3 package, which 1.2.0 can now meet.
*If that seems like a long build time, it has to set up build dependencies,
build and test four times (Python 2 & 3, normal & debug), and build the
docs. It's about an hour on i386 (which does the docs), and about half an
hour on amd64.
Thomas

Thanks. Sorry about not communicating the new dependency very well. As 
this only affects those building the docs (meaning primarily developers 
and not end-users) it wasn't given the same care.
We had had some back-and-forth about whether to include a local copy of 
numpydoc in matplotlib, but ultimately decided not to as this is 
generally not what packagers like to see. In there a way to depend on 
numpydoc from the development release in your PPA (only as a build-time 
dependency?)
Mike
On 01/26/2013 11:00 AM, Thomas Kluyver wrote:
> As a couple of people have noticed, my matplotlib-daily PPA has become 
> broken the other day, especially for 64-bit users. The root cause of 
> this is that building the docs now requires numpydoc, which is only 
> packaged in the development release of Ubuntu.
>
> I've taken this as a prompt to switch the daily recipe builds to 
> raring. I think most people who had added my PPA were interested in a 
> Python 3 package of matplotlib. So I've backported the 1.2.0 package 
> to precise and quantal, in another PPA:
>
> https://launchpad.net/~takluyver/+archive/python3 
> <https://launchpad.net/%7Etakluyver/+archive/python3>
>
> If you were using python3-matplotlib from my PPA on precise or 
> quantal, I recommend that you switch to my python3 PPA. It's actually 
> a downgrade, but it's a stable version that shouldn't do anything 
> unexpected.
>
> If people want to keep running development versions of matplotlib on 
> precise/quantal, speak up: I can reconsider turning off the daily 
> builds for those versions.
>
> Thanks,
> Thomas
> ------------
>
> Technical detail, for anyone interested: the architecture-independent 
> -data and -doc packages are built on i386. When the docs fail to 
> build, the -data package isn't created. The amd64 build succeeded, but 
> the architecture-dependent packages require a precisely matching 
> version of the -data package. apt complains that python[3]-matplotlib 
> has a missing dependency.
>
>
>
> ------------------------------------------------------------------------------
> 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/learnnow-d2d
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sun, Jan 27, 2013 at 12:28 PM, Neal Becker <ndb...@gm...> wrote:
> Damon McDougall wrote:
>
>> On Sun, Jan 27, 2013 at 11:51 AM, Neal Becker
>> <ndb...@gm...> wrote:
>>> Damon McDougall wrote:
>>>
>>>> On Sun, Jan 27, 2013 at 8:56 AM, Neal Becker
>>>> <ndb...@gm...> wrote:
>>>>> Simple example: the bars on the two x axis ends are not visible.
>>>>>
>>>>> x = [3, 6, 10]
>>>>> y = [1, 2, 3]
>>>>> import matplotlib.pyplot as plt
>>>>>
>>>>> plt.errorbar (x, y, 0.2)
>>>>
>>>> Try adding a plt.xlim(2, 11) here.
>>>>
>>>>> plt.show()
>>>>>
>>> Yes that'll fix it - but ideally autoscaling should work correctly.
>>
>> That behaviour of autoscale appears to be consistent with
>> plt.plot(range(3)), for example. That is, the axis limits butt up
>> against the plotted data.
>>
>> By 'work correctly', do you mean that the axis limits should be padded
>> so there is a whitespace border surrounding the data being plotted?
>>
>
> I think you'll agree the original result in not visually appealing or clear.
> The most obvious way to improve it would be to select axis limits a bit larger.
> At least large enough to completely show the error bar; I suspect a bit of
> whitespace would be even more clear.
Indeed, I do agree.
I have actually changed my mind about this behaviour being consistent
with plt.plot. I feel like the 'feet' on the error bars should be
taken into account during the autoscaling procedure. This will result
in the autoscaling procedure adding a small amount of whitespace such
that the feet are then visible after a call to plt.show().
I have opened a new issue on our github issue tracker. See
https://github.com/matplotlib/matplotlib/issues/1711
Thanks for reporting the problem, Neal.
-- 
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

Damon McDougall wrote:
> On Sun, Jan 27, 2013 at 11:51 AM, Neal Becker
> <ndb...@gm...> wrote:
>> Damon McDougall wrote:
>>
>>> On Sun, Jan 27, 2013 at 8:56 AM, Neal Becker
>>> <ndb...@gm...> wrote:
>>>> Simple example: the bars on the two x axis ends are not visible.
>>>>
>>>> x = [3, 6, 10]
>>>> y = [1, 2, 3]
>>>> import matplotlib.pyplot as plt
>>>>
>>>> plt.errorbar (x, y, 0.2)
>>>
>>> Try adding a plt.xlim(2, 11) here.
>>>
>>>> plt.show()
>>>>
>> Yes that'll fix it - but ideally autoscaling should work correctly.
> 
> That behaviour of autoscale appears to be consistent with
> plt.plot(range(3)), for example. That is, the axis limits butt up
> against the plotted data.
> 
> By 'work correctly', do you mean that the axis limits should be padded
> so there is a whitespace border surrounding the data being plotted?
> 
I think you'll agree the original result in not visually appealing or clear. 
The most obvious way to improve it would be to select axis limits a bit larger. 
At least large enough to completely show the error bar; I suspect a bit of 
whitespace would be even more clear.

On Sun, Jan 27, 2013 at 11:51 AM, Neal Becker <ndb...@gm...> wrote:
> Damon McDougall wrote:
>
>> On Sun, Jan 27, 2013 at 8:56 AM, Neal Becker
>> <ndb...@gm...> wrote:
>>> Simple example: the bars on the two x axis ends are not visible.
>>>
>>> x = [3, 6, 10]
>>> y = [1, 2, 3]
>>> import matplotlib.pyplot as plt
>>>
>>> plt.errorbar (x, y, 0.2)
>>
>> Try adding a plt.xlim(2, 11) here.
>>
>>> plt.show()
>>>
> Yes that'll fix it - but ideally autoscaling should work correctly.
That behaviour of autoscale appears to be consistent with
plt.plot(range(3)), for example. That is, the axis limits butt up
against the plotted data.
By 'work correctly', do you mean that the axis limits should be padded
so there is a whitespace border surrounding the data being plotted?
-- 
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

Damon McDougall wrote:
> On Sun, Jan 27, 2013 at 8:56 AM, Neal Becker
> <ndb...@gm...> wrote:
>> Simple example: the bars on the two x axis ends are not visible.
>>
>> x = [3, 6, 10]
>> y = [1, 2, 3]
>> import matplotlib.pyplot as plt
>>
>> plt.errorbar (x, y, 0.2)
> 
> Try adding a plt.xlim(2, 11) here.
> 
>> plt.show()
>>
Yes that'll fix it - but ideally autoscaling should work correctly.

On Sun, Jan 27, 2013 at 8:56 AM, Neal Becker <ndb...@gm...> wrote:
> Simple example: the bars on the two x axis ends are not visible.
>
> x = [3, 6, 10]
> y = [1, 2, 3]
> import matplotlib.pyplot as plt
>
> plt.errorbar (x, y, 0.2)
Try adding a plt.xlim(2, 11) here.
> plt.show()
>
>
>
> ------------------------------------------------------------------------------
> 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/learnnow-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
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

Simple example: the bars on the two x axis ends are not visible.
x = [3, 6, 10]
y = [1, 2, 3]
import matplotlib.pyplot as plt
plt.errorbar (x, y, 0.2)
plt.show()

As a couple of people have noticed, my matplotlib-daily PPA has become
broken the other day, especially for 64-bit users. The root cause of this
is that building the docs now requires numpydoc, which is only packaged in
the development release of Ubuntu.
I've taken this as a prompt to switch the daily recipe builds to raring. I
think most people who had added my PPA were interested in a Python 3
package of matplotlib. So I've backported the 1.2.0 package to precise and
quantal, in another PPA:
https://launchpad.net/~takluyver/+archive/python3
If you were using python3-matplotlib from my PPA on precise or quantal, I
recommend that you switch to my python3 PPA. It's actually a downgrade, but
it's a stable version that shouldn't do anything unexpected.
If people want to keep running development versions of matplotlib on
precise/quantal, speak up: I can reconsider turning off the daily builds
for those versions.
Thanks,
Thomas
------------
Technical detail, for anyone interested: the architecture-independent -data
and -doc packages are built on i386. When the docs fail to build, the -data
package isn't created. The amd64 build succeeded, but the
architecture-dependent packages require a precisely matching version of the
-data package. apt complains that python[3]-matplotlib has a missing
dependency.

On 01/16/2013 12:18 PM, Michael Droettboom wrote:
> There have been bits and pieces of discussion about future releases on
> PRs, and I thought I'd bring it over here to tie loose ends together.
>
> There have been 83 commits since 1.2.0 -- it's probably time to start
> thinking about a 1.2.1. The release candidate cycle shouldn't be as
> long for this, as it's only a bugfix release. If you are aware of any
> issues or PRs in the tracker that make sense for 1.2.1 (i.e. simple
> bugfixes), please assign to the 1.2.x milestone. Once that milestone is
> empty, sometime next week I will probably put out a 1.2.1rc1.
>
Thanks again for all the bug triaging and assignment that's gone on. We 
have 6 issues marked 1.2.x or 1.2.1 to sort through, which I think 
shouldn't be so bad, but we probably won't get through them today, so 
I'm going to push the 1.2.1rc1 candidate into next week.
Cheers,
Mike

On Thu, Jan 17, 2013 at 6:33 AM, Todd <tod...@gm...> wrote:
> On Thu, Jan 17, 2013 at 11:30 AM, Todd <tod...@gm...> wrote:
>
>> On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson <pel...@gm...>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 propose setters such as
>>> Axes.set_xlim might make use of properties. The particular example I
>>> have picked uses keywords to determine the behaviours of the method itself:
>>>
>>> def set_xlim(self, left=None, right=None, emit=True, auto=False, **kw):
>>> ...
>>>
>>>
>>> For me, the backwards compatibility issue is the key blocker to this
>>> MEP. Would you mind providing some concrete examples (perhaps using the
>>> set_xlim method as a focus point)?
>>>
>>> Cheers,
>>>
>>> Phil
>>>
>>>
>> Methods like that will be a problem. I see two possible approaches
>> (which are not mutually exclusive):
>>
>> 1. keep the set_xlim method for more sophisticated cases.
>> 2. split the set_xlim method into several methods
>>
>> Frankly I am not sure deprecating the existing setter and getter methods
>> is really called for. It may not be worth the trouble for users. That is
>> why I said everything in the MEP is very tentative.
>>
>> For approach 1, we would keep the current method, but also have another
>> method:
>>
>> @xlim.setter
>> def xlim(self, lims):
>> ...
>>
>> so for the basic case, just setting the lims, you would do:
>>
>> axesobj.xlims = (leftval, rightval)
>>
>> For approach 2, you would have additionally have (there is already an
>> autoscale_x_on method):
>>
>> @autoscale_x.setter
>> def autoscale_x(self, auto):
>> ...
>>
>>
>> @emit_xlim.setter
>> def emit_xlim(self, emit):
>> ...
>>
>>
>> @xlim_left.setter
>> def xlim_left(self, left):
>> ...
>>
>>
>> @xlim_right.setter
>> def xlim_right(self, rigth):
>> ...
>>
>> (or you could do some python-fu to allow you to assign values to the
>> xlim[0] and xlim[1])
>>
>> This would require setting three separate attributes. However, we would
>> already have the autoscale_x property.
>>
>> In my opinion breaking up the API into separate calls would be a cleaner
>> approach anyway. Setters and getters should be setters and getters, they
>> shouldn't be modifying other unrelated values. But that does not mean we
>> have to remove the existing approach.
>>
>>
>>
>>
>
> I've added examples of two examples of difficult cases to the MEP. I've
> also added more specific details of how to deal with them.
>
> The MEP is still written under the assumption that we will ultimately
> deprecate the existing setter and getter methods but, as I said, whether
> this is the best approach is highly questionable.
>
>
My take is that things like xlims, titles and such probably shouldn't be
made into properties quite yet. They are more complex beasts. I am more
concerned about the simplification of the API w.r.t. the attributes of the
artist objects such as edgecolor, linewidth, facecolor, fontsize, etc....
It is these things down at the OO level that feels very klunky.
Cheers!
Ben Root

On Mon, Jan 21, 2013 at 11:44 AM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Just ran across this article that shows a familiar looking graph. Just
> another encounter of matplotlib in daily life.
>
> http://www.wired.com/wiredenterprise/2013/01/google-password/2/
Here's another one, too:
http://www.wired.com/wiredscience/2013/01/why-are-lego-sets-expensive/
Maybe the next wired article will use the SVG backend :)
>
> Ryan
>
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
> ------------------------------------------------------------------------------
> 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
>
-- 
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

Hi,
Just ran across this article that shows a familiar looking graph. Just
another encounter of matplotlib in daily life.
http://www.wired.com/wiredenterprise/2013/01/google-password/2/
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jan 17, 2013 at 11:30 AM, Todd <tod...@gm...> wrote:
> On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson <pel...@gm...> 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 propose setters such as
>> Axes.set_xlim might make use of properties. The particular example I
>> have picked uses keywords to determine the behaviours of the method itself:
>>
>> def set_xlim(self, left=None, right=None, emit=True, auto=False, **kw):
>> ...
>>
>>
>> For me, the backwards compatibility issue is the key blocker to this MEP.
>> Would you mind providing some concrete examples (perhaps using the set_xlim
>> method as a focus point)?
>>
>> Cheers,
>>
>> Phil
>>
>>
> Methods like that will be a problem. I see two possible approaches (which
> are not mutually exclusive):
>
> 1. keep the set_xlim method for more sophisticated cases.
> 2. split the set_xlim method into several methods
>
> Frankly I am not sure deprecating the existing setter and getter methods
> is really called for. It may not be worth the trouble for users. That is
> why I said everything in the MEP is very tentative.
>
> For approach 1, we would keep the current method, but also have another
> method:
>
> @xlim.setter
> def xlim(self, lims):
> ...
>
> so for the basic case, just setting the lims, you would do:
>
> axesobj.xlims = (leftval, rightval)
>
> For approach 2, you would have additionally have (there is already an
> autoscale_x_on method):
>
> @autoscale_x.setter
> def autoscale_x(self, auto):
> ...
>
>
> @emit_xlim.setter
> def emit_xlim(self, emit):
> ...
>
>
> @xlim_left.setter
> def xlim_left(self, left):
> ...
>
>
> @xlim_right.setter
> def xlim_right(self, rigth):
> ...
>
> (or you could do some python-fu to allow you to assign values to the
> xlim[0] and xlim[1])
>
> This would require setting three separate attributes. However, we would
> already have the autoscale_x property.
>
> In my opinion breaking up the API into separate calls would be a cleaner
> approach anyway. Setters and getters should be setters and getters, they
> shouldn't be modifying other unrelated values. But that does not mean we
> have to remove the existing approach.
>
>
>
>
I've added examples of two examples of difficult cases to the MEP. I've
also added more specific details of how to deal with them.
The MEP is still written under the assumption that we will ultimately
deprecate the existing setter and getter methods but, as I said, whether
this is the best approach is highly questionable.

On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson <pel...@gm...> 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 propose setters such as
> Axes.set_xlim might make use of properties. The particular example I have
> picked uses keywords to determine the behaviours of the method itself:
>
> def set_xlim(self, left=None, right=None, emit=True, auto=False, **kw):
> ...
>
>
> For me, the backwards compatibility issue is the key blocker to this MEP.
> Would you mind providing some concrete examples (perhaps using the set_xlim
> method as a focus point)?
>
> Cheers,
>
> Phil
>
>
Methods like that will be a problem. I see two possible approaches (which
are not mutually exclusive):
1. keep the set_xlim method for more sophisticated cases.
2. split the set_xlim method into several methods
Frankly I am not sure deprecating the existing setter and getter methods is
really called for. It may not be worth the trouble for users. That is why
I said everything in the MEP is very tentative.
For approach 1, we would keep the current method, but also have another
method:
@xlim.setter
def xlim(self, lims):
 ...
so for the basic case, just setting the lims, you would do:
axesobj.xlims = (leftval, rightval)
For approach 2, you would have additionally have (there is already an
autoscale_x_on method):
@autoscale_x.setter
def autoscale_x(self, auto):
 ...
@emit_xlim.setter
def emit_xlim(self, emit):
 ...
@xlim_left.setter
def xlim_left(self, left):
 ...
@xlim_right.setter
def xlim_right(self, rigth):
 ...
(or you could do some python-fu to allow you to assign values to the
xlim[0] and xlim[1])
This would require setting three separate attributes. However, we would
already have the autoscale_x property.
In my opinion breaking up the API into separate calls would be a cleaner
approach anyway. Setters and getters should be setters and getters, they
shouldn't be modifying other unrelated values. But that does not mean we
have to remove the existing approach.

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 propose setters such as
Axes.set_xlim might make use of properties. The particular example I have
picked uses keywords to determine the behaviours of the method itself:
def set_xlim(self, left=None, right=None, emit=True, auto=False, **kw):
 ...
For me, the backwards compatibility issue is the key blocker to this MEP.
Would you mind providing some concrete examples (perhaps using the set_xlim
method as a focus point)?
Cheers,
Phil
On 16 January 2013 21:00, Todd <tod...@gm...> wrote:
> 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.
>
>
> ------------------------------------------------------------------------------
> 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 Wed, Jan 16, 2013 at 2:52 PM, Michael Droettboom <md...@st...> 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 created a MEP on the subject, MEP13, and a new mailing list thread
to discuss it.

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 Jan 16, 2013 2:05 PM, "Todd" <tod...@gm...> wrote:
>
> On Wed, Jan 16, 2013 at 2:55 PM, Benjamin Root <ben...@ou...> wrote:
>>
>>
>> On Wed, Jan 16, 2013 at 2:42 PM, Todd <tod...@gm...> wrote:
>>>
>>> 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?
>>>
>>
>> This was actually discussed during a Birds of a Feather (BOF) meeting
back in SciPy2012 (which John Hunter attended). I am definitely for the
idea, but it is going to be a very painful and long deprecation process.
>>
> Is there a reason we have to deprecate the current method? They are not
mutually-exclusive.
>
Also along these lines, it's relatively easy to write a metaclass to make
everything with an explicit set and get method have a property as well.
It's a bit on the magical side, but not too bad.
There are a few things that would have name clashes (e.g. ax.figure and
ax.set_figure) but the vast majority of these would only require manual
code tweaking and would not require an api change, as they already behave
as the property would.
This way you could still have setp and the like along with the properties
and avoid any depreciation. It also would only require minimal code changes
(but significant documentation additions).
Just my two cents, anyway.
>
>
------------------------------------------------------------------------------
> 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 Wed, Jan 16, 2013 at 3:05 PM, Todd <tod...@gm...> wrote:
> On Wed, Jan 16, 2013 at 2:55 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>> On Wed, Jan 16, 2013 at 2:42 PM, Todd <tod...@gm...> wrote:
>>
>>> 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?
>>>
>>>
>> This was actually discussed during a Birds of a Feather (BOF) meeting
>> back in SciPy2012 (which John Hunter attended). I am definitely for the
>> idea, but it is going to be a very painful and long deprecation process.
>>
>> Is there a reason we have to deprecate the current method? They are not
> mutually-exclusive.
>
>
But, then what is the gain of switching to the properties approach?
Properties allows you to clean up one's API, and also enables
code-execution upon get/sets. We don't really have much of a need for the
latter, except in a few places. I would see a move to properties as a way
to clean up our API back to the just the getp() setp() approach for
portability with matlab.
Note, I am a fan of moving to properties, but all of this will have to be
thought-out.
Ben Root

On Wed, Jan 16, 2013 at 10:54 AM, Todd <tod...@gm...> wrote:
> On Jan 16, 2013 9:30 AM, "Fernando Perez" <fpe...@gm...> wrote:
>>
>> On Wed, Jan 16, 2013 at 12:10 AM, Nelle Varoquaux
>> <nel...@gm...> 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 the list and we can look into
>> what can be done, esp. in a way that could also help other projects as
>> well.
>>
>> Also, there's snakebite: http://www.snakebite.net. The project seemed
>> very dormant for a long time, but there's been some activity since:
>> http://www.snakebite.net/network. I'd ping Titus Brown on Twitter
>> (@ctitusbrown) for info...
>>
>> Cheers,
>
> There is also the open build service, which is more of a build farm but can
> be set up pull, build, test, and publish git snapshots for most common Linux
> distributions to your own online software repository simultaneously with one
> click on a website or one commandline call.
>
> https://build.opensuse.org/
>
> They provide hosting, building, and distribution for free. You can probably
> set up a script to automatically rebuild master on a change, or daily.
> However, setting it up to test individual commits would be overly difficult
> and probably be seen as an abuse of the system. Using it to always build,
> test, and release offer the latest master to most linux distros, on the
> other hand, would be fine. If someone contacts them they can probably set
> up a repository just for you, or if this sort of thing is useful a more
> general repository you can share with others (there is already
> devel:languages:python, maybe devel:languages:python:unstable).
>
> You can also use it to build release rpms and debs for various distros. It
> is already being used to build the packages discussed so far for openSUSE,
> but if someone is willing to maintain them they can be built for other
> distros as well.
GitHub allow for a custom service-hook. If, as Mike says, it's not too
hard to garner compute cycles, it shouldn't be too hard to write a
small script to execute the test suite when the github repo receives a
push.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On Wed, Jan 16, 2013 at 2:55 PM, Benjamin Root <ben...@ou...> wrote:
>
> On Wed, Jan 16, 2013 at 2:42 PM, Todd <tod...@gm...> wrote:
>
>> 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?
>>
>>
> This was actually discussed during a Birds of a Feather (BOF) meeting back
> in SciPy2012 (which John Hunter attended). I am definitely for the idea,
> but it is going to be a very painful and long deprecation process.
>
> Is there a reason we have to deprecate the current method? They are not
mutually-exclusive.

On Wed, Jan 16, 2013 at 2:42 PM, Todd <tod...@gm...> wrote:
> 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?
>
>
This was actually discussed during a Birds of a Feather (BOF) meeting back
in SciPy2012 (which John Hunter attended). I am definitely for the idea,
but it is going to be a very painful and long deprecation process. A bit
of background (at least, my understanding of it)...
In matlab, there is the setp and getp functions. With this, you can set
and get properties of various graphing objects. It is this feature that
John duplicated, and it is the organic growth from there is why we are
where we are now.
Furthermore, for those who haven't noticed, we have a strange "alias"
feature. For example, one could set edgecolor, but also ec, to the same
effect. In a lark, I decided to trace down this feature and, to my horror,
discovered how it works. Believe it or not, the docstring for
set_edgecolor (or get_edgecolor, I forget) mentions that "ec" is an alias,
and there is code elsewhere that processes the docstrings, looking for
mentions of aliases, and uses that to guide the setting of properties. Of
course, don't forget that sometimes we do the plural of a property name as
well...
Rather than keeping these attributes as a part of the artist objects, I
would rather encapsulate the artist properties using a new Properties class
(maybe it subclasses from dict?). This would make it easier to apply/share
properties between many objects, and be more future-proof.
My 2 cents,
Ben Root