Re: [matplotlib-devel] Question about getters and setters.

2015-05-14 Thread Eric Firing 
On 2015/05/13 7:45 PM, Brian Granger wrote:
> We (ipython/jupyter) have been talking some more about integrating
> matplotlilb in deeper ways with the interactive widgets framework. That
> only thing that would be required to make this *trivial* is having a
> traitlet's based API for matplotlib. I have even started to look at
> wrapping the existing mpl OO API using traitlets to start to explore
> this. Once this was done, it would be quite easy to autogenerate UIs for
> any aspect of Matplotlib.
>
> Now that traitlets is a standalone pure python package:
>
> https://github.com/ipython/traitlets
>
> this would be much easier to pull off.
>
> If there is interest in this, we might even be able to help do some of
> the work. Let us know if there is enough interest to discuss this further.

No question about it: there is more than enough interest.

Eric

>
> Cheers,
>
> Brian
>
> On Wed, May 13, 2015 at 9:36 PM, Eric Firing  > wrote:
>
> On 2015/05/13 5:47 PM, Neil Girdhar wrote:
> > You're right.  My angle is I just want the setters and getters.  Writing
> > set_ and get_ feels like the C++ prison I thought I had escaped :)
> >
> John Hunter once commented that if he were doing it over again he would
> not have put in all the set_ and get_; they were a legacy of his origins
> as a C++ programmer.  I think he would have started with simple
> attributes, which would have been adequate in the early stages.
> Properties were very new--only introduced in Python 2.2, at the end
> of 2001.
>
> Eric
>
> 
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> bgran...@calpoly.edu  and
> elliso...@gmail.com 


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Question about getters and setters.

2015-05-14 Thread Brian Granger 
Great, that is exciting. What do you think is the best way forward? Should
I open an issue on the matplotlib repo about this? Would there be interest
in doing a Google+ hangout about this at some point?

On Wed, May 13, 2015 at 11:57 PM, Eric Firing  wrote:

> On 2015/05/13 7:45 PM, Brian Granger wrote:
>
>> We (ipython/jupyter) have been talking some more about integrating
>> matplotlilb in deeper ways with the interactive widgets framework. That
>> only thing that would be required to make this *trivial* is having a
>> traitlet's based API for matplotlib. I have even started to look at
>> wrapping the existing mpl OO API using traitlets to start to explore
>> this. Once this was done, it would be quite easy to autogenerate UIs for
>> any aspect of Matplotlib.
>>
>> Now that traitlets is a standalone pure python package:
>>
>> https://github.com/ipython/traitlets
>>
>> this would be much easier to pull off.
>>
>> If there is interest in this, we might even be able to help do some of
>> the work. Let us know if there is enough interest to discuss this further.
>>
>
> No question about it: there is more than enough interest.
>
> Eric
>
>
>> Cheers,
>>
>> Brian
>>
>> On Wed, May 13, 2015 at 9:36 PM, Eric Firing > > wrote:
>>
>> On 2015/05/13 5:47 PM, Neil Girdhar wrote:
>> > You're right.  My angle is I just want the setters and getters.
>> Writing
>> > set_ and get_ feels like the C++ prison I thought I had escaped :)
>> >
>> John Hunter once commented that if he were doing it over again he
>> would
>> not have put in all the set_ and get_; they were a legacy of his
>> origins
>> as a C++ programmer.  I think he would have started with simple
>> attributes, which would have been adequate in the early stages.
>> Properties were very new--only introduced in Python 2.2, at the end
>> of 2001.
>>
>> Eric
>>
>>
>> --
>> One dashboard for servers and applications across
>> Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable
>> Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> 
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> @ellisonbg on Twitter and GitHub
>> bgran...@calpoly.edu  and
>> elliso...@gmail.com 
>>
>
>


-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgran...@calpoly.edu and elliso...@gmail.com
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] python nightly failures

2015-05-14 Thread Jens Nielsen 
Thanks for tracing this Tom. I was meaning to look into it but never got
round to it.

Jens

tor. 14. maj 2015 kl. 03.30 skrev Juan Nunez-Iglesias :

> Thanks Tom! Absolutely fascinating! I was trying to grok this and
> thinking, "but what if we want 'or' to return a value that will later be
> used as a conditional, surely it should return bool?" But of course
> whatever it returns will be correctly interpreted as a bool in a
> conditional context! Delayed/lazy bool casting, in a sense. Very clever
> indeed.
>
> There's quite a few places where this would make my code quite a bit
> cleaner! =)
>
> Thanks again!
>
> Juan.
>
> On Thu, May 14, 2015 at 12:21 PM, Thomas Caswell 
> wrote:
>
>> The `a or b` syntax evaluates if a is 'trueish' and if so returns a if
>> not returns b so `c = None or {}` -> c == {}  but `c = {'a': 1} or {}` -> c
>> == {'a': 1}
>>
>> See
>> https://docs.python.org/3.5/reference/expressions.html#grammar-token-or_test
>> for the docs on or. and works almost the same, but returns a if a is False
>> and b in a is True.
>>
>> In the grammar for calls it should be looking for thing like "'**'
>> expression" which means in the parsing anything that is part of the
>> expression gets evaluated before the unpacking of the mapping.  If you
>> chase far enough back in the grammar an 'or_test' is an 'expression' (I may
>> be butchering the terminology here, only just learned how lexing/parsing
>> works a few weeks ago) so it should be fully evaluated before trying to
>> unpack.
>>
>> See https://docs.python.org/3.5/reference/expressions.html#calls for the
>> official docs.
>>
>> I suspect the source of this bug is that the grammar is getting
>> rearranged a bit to allow for things like d = {**other_dict, 'x':6}  and b
>> = (*a, *c) to work as expected and something did not get changed quite
>> right.
>>
>> Tom
>>
>> On Wed, May 13, 2015 at 8:33 PM Juan Nunez-Iglesias 
>> wrote:
>>
>>> Fascinating! Can you "unpack" (heh) that error for us mere mortals? In
>>> particular:
>>>
>>> - never seen that "or" syntax before... Is it coercing both expressions
>>> as bool, or is it evaluating to left if bool(left) evaluates to True, else
>>> to right?
>>> - Why do you expect the second expression to work? Is ** supposed to
>>> have lower preference than "or"? (Which seems weird to me.)
>>>
>>> Thanks!
>>>
>>> Juan.
>>>
>>> On Thu, May 14, 2015 at 5:08 AM, Thomas Caswell 
>>> wrote:
>>>

 The failures on python nightly are currently due to a bug in python (
 http://bugs.python.org/issue24176)

 Tom


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


>>>
>>> --
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>> ___
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
http

Re: [matplotlib-devel] Question about getters and setters.

2015-05-14 Thread Benjamin Root 
You could start up a Pull Request describing a MEP that would outline how
traitlets would be used. The discussion can go on there to flesh out the
concepts and the guidance documentation. Once that is agreed upon, that PR
would get merged, and we can then start up a new PR actually implementing
the MEP.

On Thu, May 14, 2015 at 3:03 AM, Brian Granger  wrote:

> Great, that is exciting. What do you think is the best way forward? Should
> I open an issue on the matplotlib repo about this? Would there be interest
> in doing a Google+ hangout about this at some point?
>
> On Wed, May 13, 2015 at 11:57 PM, Eric Firing  wrote:
>
>> On 2015/05/13 7:45 PM, Brian Granger wrote:
>>
>>> We (ipython/jupyter) have been talking some more about integrating
>>> matplotlilb in deeper ways with the interactive widgets framework. That
>>> only thing that would be required to make this *trivial* is having a
>>> traitlet's based API for matplotlib. I have even started to look at
>>> wrapping the existing mpl OO API using traitlets to start to explore
>>> this. Once this was done, it would be quite easy to autogenerate UIs for
>>> any aspect of Matplotlib.
>>>
>>> Now that traitlets is a standalone pure python package:
>>>
>>> https://github.com/ipython/traitlets
>>>
>>> this would be much easier to pull off.
>>>
>>> If there is interest in this, we might even be able to help do some of
>>> the work. Let us know if there is enough interest to discuss this
>>> further.
>>>
>>
>> No question about it: there is more than enough interest.
>>
>> Eric
>>
>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> On Wed, May 13, 2015 at 9:36 PM, Eric Firing >> > wrote:
>>>
>>> On 2015/05/13 5:47 PM, Neil Girdhar wrote:
>>> > You're right.  My angle is I just want the setters and getters.
>>> Writing
>>> > set_ and get_ feels like the C++ prison I thought I had escaped :)
>>> >
>>> John Hunter once commented that if he were doing it over again he
>>> would
>>> not have put in all the set_ and get_; they were a legacy of his
>>> origins
>>> as a C++ programmer.  I think he would have started with simple
>>> attributes, which would have been adequate in the early stages.
>>> Properties were very new--only introduced in Python 2.2, at the end
>>> of 2001.
>>>
>>> Eric
>>>
>>>
>>> --
>>> One dashboard for servers and applications across
>>> Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable
>>> Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>> ___
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> 
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>>
>>>
>>> --
>>> Brian E. Granger
>>> Cal Poly State University, San Luis Obispo
>>> @ellisonbg on Twitter and GitHub
>>> bgran...@calpoly.edu  and
>>> elliso...@gmail.com 
>>>
>>
>>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> bgran...@calpoly.edu and elliso...@gmail.com
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel