I don’t want to ruffle any feathers, and I’m sure this comes up all the time, but I’m wondering why don’t we have a decorator on classes that generates all of the boilerplate methods?
For example:
@generate_boilerplate([(‘linestyle’, ‘ls’), …]
class Patch(…):
would generate
get_ls, set_ls to point to get_linestyle and set_linestyle and their docstrings
and would generate
linestyle = property(get_linestyle, set_linestyle) and their docstring.
This would reduce a lot of boilerplate code and provide the modern getters and setters. In the future, a user could enable an option to disable the old style interface and remove it from ‘dir’, etc.
What’s the reason for not providing the “new”-style getters and setters?
It is my understanding that most of this code pre-dates properties and going through and updating all of the classes is a huge amount of work. It is more a matter of time than will.
There is also a slowly simmering discussion about implementing artists in a managed property/attribute frame work (either traitlets, param, or rolling our own) which is related to this.
···
On Wed, May 13, 2015 at 11:06 PM Neil Girdhar <mistersheik@…149…> wrote:
I don’t want to ruffle any feathers, and I’m sure this comes up all the time, but I’m wondering why don’t we have a decorator on classes that generates all of the boilerplate methods?
For example:
@generate_boilerplate([(‘linestyle’, ‘ls’), …]
class Patch(…):
would generate
get_ls, set_ls to point to get_linestyle and set_linestyle and their docstrings
and would generate
linestyle = property(get_linestyle, set_linestyle) and their docstring.
This would reduce a lot of boilerplate code and provide the modern getters and setters. In the future, a user could enable an option to disable the old style interface and remove it from ‘dir’, etc.
What’s the reason for not providing the “new”-style getters and setters?
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
Manpower, really. Also, there be dragons deep in that code (I’ll leave it as an exploration task for you to figure out how aliases are done).
There have been a few proposals, but they keep suffering from scope creep. Take a look at the MEP page.
Keep in mind that reducing Lines of Code just for the sake of reducing lines of code isn’t all that useful. The current code isn’t broken, and there are no plans to add more properties, so it isn’t much of a hinderance (compared to other aspects of the codebase). But a proposal that makes validation and style-handling (or some such) would be valuable.
Cheers!
Ben Root
···
On May 13, 2015 11:06 PM, “Neil Girdhar” <mistersheik@…149…> wrote:
I don’t want to ruffle any feathers, and I’m sure this comes up all the time, but I’m wondering why don’t we have a decorator on classes that generates all of the boilerplate methods?
For example:
@generate_boilerplate([(‘linestyle’, ‘ls’), …]
class Patch(…):
would generate
get_ls, set_ls to point to get_linestyle and set_linestyle and their docstrings
and would generate
linestyle = property(get_linestyle, set_linestyle) and their docstring.
This would reduce a lot of boilerplate code and provide the modern getters and setters. In the future, a user could enable an option to disable the old style interface and remove it from ‘dir’, etc.
What’s the reason for not providing the “new”-style getters and setters?
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
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 
I’ll keep an eye for the discussion on this topic since this is interesting to me for other reasons as well. (I had to code something like params for my own code).
Best,
Neil
···
On Wed, May 13, 2015 at 11:42 PM, Benjamin Root <ben.root@…553…> wrote:
Manpower, really. Also, there be dragons deep in that code (I’ll leave it as an exploration task for you to figure out how aliases are done).
There have been a few proposals, but they keep suffering from scope creep. Take a look at the MEP page.
Keep in mind that reducing Lines of Code just for the sake of reducing lines of code isn’t all that useful. The current code isn’t broken, and there are no plans to add more properties, so it isn’t much of a hinderance (compared to other aspects of the codebase). But a proposal that makes validation and style-handling (or some such) would be valuable.
Cheers!
Ben Root
On May 13, 2015 11:06 PM, “Neil Girdhar” <mistersheik@…149…> wrote:
I don’t want to ruffle any feathers, and I’m sure this comes up all the time, but I’m wondering why don’t we have a decorator on classes that generates all of the boilerplate methods?
For example:
@generate_boilerplate([(‘linestyle’, ‘ls’), …]
class Patch(…):
would generate
get_ls, set_ls to point to get_linestyle and set_linestyle and their docstrings
and would generate
linestyle = property(get_linestyle, set_linestyle) and their docstring.
This would reduce a lot of boilerplate code and provide the modern getters and setters. In the future, a user could enable an option to disable the old style interface and remove it from ‘dir’, etc.
What’s the reason for not providing the “new”-style getters and setters?
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
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
···
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
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.
Cheers,
Brian
···
On Wed, May 13, 2015 at 9:36 PM, Eric Firing <efiring@…229…> 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
bgranger@…882… and ellisonbg@…149…
This is very exciting! traitlets looks really nice. (Imho better than params from my cursory look.)
···
On Thu, May 14, 2015 at 1:45 AM, Brian Granger <ellisonbg@…149…> 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.
Cheers,
Brian
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
On Wed, May 13, 2015 at 9:36 PM, Eric Firing <efiring@…229…> 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
bgranger@…882… and ellisonbg@…149…
–
I should note that all of ipython is based on traitlets, so by now it is very stable, battle tested (also actively developed). For base layers like this, I think that is important.
···
On Wed, May 13, 2015 at 11:27 PM, Neil Girdhar <mistersheik@…149…> wrote:
This is very exciting! traitlets looks really nice. (Imho better than params from my cursory look.)
–
On Thu, May 14, 2015 at 1:45 AM, Brian Granger <ellisonbg@…149…> 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.
Cheers,
Brian
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
On Wed, May 13, 2015 at 9:36 PM, Eric Firing <efiring@…229…> 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
bgranger@…882… and ellisonbg@…55…149…
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…882… and ellisonbg@…149…
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:
GitHub - ipython/traitlets: A lightweight Traits like module
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
···
On 2015/05/13 7:45 PM, Brian Granger wrote:
Cheers,
Brian
On Wed, May 13, 2015 at 9:36 PM, Eric Firing <efiring@...229... > <mailto:efiring@…229…>> 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.
Application Monitor Software & Tools - ManageEngine Applications Manager
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
matplotlib-devel List Signup and Options
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@...882... <mailto:bgranger@…882…> and
ellisonbg@...149... <mailto:ellisonbg@…149…>
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 <efiring@…229…> 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.
On 2015/05/13 7:45 PM, Brian Granger wrote:
No question about it: there is more than enough interest.
Eric
Cheers,
Brian
On Wed, May 13, 2015 at 9:36 PM, Eric Firing <efiring@…229…
mailto:efiring@...55.....229...> 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](http://ad.doubleclick.net/ddm/clk/290420510;117567292;y)
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
[https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…552…882… mailto:bgranger@...882... and
ellisonbg@…714… mailto:ellisonbg@...149...
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…882… and ellisonbg@…149…
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 <ellisonbg@…149…> 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?
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
On Wed, May 13, 2015 at 11:57 PM, Eric Firing <efiring@…229…> 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.
On 2015/05/13 7:45 PM, Brian Granger wrote:
No question about it: there is more than enough interest.
Eric
Cheers,
Brian
On Wed, May 13, 2015 at 9:36 PM, Eric Firing <efiring@…229…
mailto:efiring@...55.....229...> 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](http://ad.doubleclick.net/ddm/clk/290420510;117567292;y)
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
[https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…552…882… mailto:bgranger@...882... and
ellisonbg@…714… mailto:ellisonbg@...149...
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…882… and ellisonbg@…761…
OK i have the MEP for this on my todo list…
···
On Thu, May 14, 2015 at 5:47 AM, Benjamin Root <ben.root@…553…> wrote:
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 <ellisonbg@…149…> 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?
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
On Wed, May 13, 2015 at 11:57 PM, Eric Firing <efiring@…229…> 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.
On 2015/05/13 7:45 PM, Brian Granger wrote:
No question about it: there is more than enough interest.
Eric
Cheers,
Brian
On Wed, May 13, 2015 at 9:36 PM, Eric Firing <efiring@…229…
mailto:efiring@...55.....229...> 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](http://ad.doubleclick.net/ddm/clk/290420510;117567292;y)
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
[https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…552…882… mailto:bgranger@...882... and
ellisonbg@…714… mailto:ellisonbg@...149...
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…882… and ellisonbg@…149…
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…882… and ellisonbg@…149…
There is a proof-of-concept implementation of this by Matthias
http://carreau.github.io/posts/09-Matplotlib-And-IPython-Config.html
Tom
···
On Thu, May 14, 2015 at 5:47 AM, Benjamin Root <ben.root@…553…> wrote:
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.
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…882… and ellisonbg@…149…
On Thu, May 14, 2015 at 3:03 AM, Brian Granger <ellisonbg@…714…> 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?
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
On Wed, May 13, 2015 at 11:57 PM, Eric Firing <efiring@…229…> 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.
On 2015/05/13 7:45 PM, Brian Granger wrote:
No question about it: there is more than enough interest.
Eric
Cheers,
Brian
On Wed, May 13, 2015 at 9:36 PM, Eric Firing <efiring@…229…
mailto:efiring@...55.....229...> 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](http://ad.doubleclick.net/ddm/clk/290420510;117567292;y)
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
<mailto:Matplotlib-devel@lists.sourceforge.net>
[https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…552…882… mailto:bgranger@...882... and
ellisonbg@…714… mailto:ellisonbg@...149...
–
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@…882… and ellisonbg@…149…