Question about getters and setters.

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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

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:

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

···

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 :slight_smile:
    >
    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
    <mailto: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… <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…