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 <mis...@gm...> 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
> Mat...@li...
> 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" <mis...@gm...> 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
> Mat...@li...
> 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...@ou...> 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" <mis...@gm...> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
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
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 <ef...@ha...> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgr...@ca... and ell...@gm...
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 <ell...@gm...> 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 > > On Wed, May 13, 2015 at 9:36 PM, Eric Firing <ef...@ha...> 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 >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > @ellisonbg on Twitter and GitHub > bgr...@ca... and ell...@gm... > > > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
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 <mis...@gm...> 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 <ell...@gm...> > 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 >> >> On Wed, May 13, 2015 at 9:36 PM, Eric Firing <ef...@ha...> 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 >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgr...@ca... and ell...@gm... >> >> >> ------------------------------------------------------------------------------ >> 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 >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgr...@ca... and ell...@gm...
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 <ef...@ha... > <mailto:ef...@ha...>> 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 > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > @ellisonbg on Twitter and GitHub > bgr...@ca... <mailto:bgr...@ca...> and > ell...@gm... <mailto:ell...@gm...>
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 <ef...@ha...> 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 <ef...@ha... >> <mailto:ef...@ha...>> 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 >> Mat...@li... >> <mailto:Mat...@li...> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgr...@ca... <mailto:bgr...@ca...> and >> ell...@gm... <mailto:ell...@gm...> >> > > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgr...@ca... and ell...@gm...
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 <ell...@gm...> 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 <ef...@ha...> 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 <ef...@ha... >>> <mailto:ef...@ha...>> 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 >>> Mat...@li... >>> <mailto:Mat...@li...> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >>> >>> >>> -- >>> Brian E. Granger >>> Cal Poly State University, San Luis Obispo >>> @ellisonbg on Twitter and GitHub >>> bgr...@ca... <mailto:bgr...@ca...> and >>> ell...@gm... <mailto:ell...@gm...> >>> >> >> > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > @ellisonbg on Twitter and GitHub > bgr...@ca... and ell...@gm... > > > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
OK i have the MEP for this on my todo list... On Thu, May 14, 2015 at 5:47 AM, Benjamin Root <ben...@ou...> 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 <ell...@gm...> > 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 <ef...@ha...> 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 <ef...@ha... >>>> <mailto:ef...@ha...>> 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 >>>> Mat...@li... >>>> <mailto:Mat...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>> >>>> >>>> >>>> >>>> -- >>>> Brian E. Granger >>>> Cal Poly State University, San Luis Obispo >>>> @ellisonbg on Twitter and GitHub >>>> bgr...@ca... <mailto:bgr...@ca...> and >>>> ell...@gm... <mailto:ell...@gm...> >>>> >>> >>> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgr...@ca... and ell...@gm... >> >> >> ------------------------------------------------------------------------------ >> 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 >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgr...@ca... and ell...@gm...
There is a proof-of-concept implementation of this by Matthias http://carreau.github.io/posts/09-Matplotlib-And-IPython-Config.html Tom On Fri, May 15, 2015 at 4:40 PM Brian Granger <ell...@gm...> wrote: > OK i have the MEP for this on my todo list... > > On Thu, May 14, 2015 at 5:47 AM, Benjamin Root <ben...@ou...> 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 <ell...@gm...> >> 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 <ef...@ha...> >>> 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 <ef...@ha... >>>>> <mailto:ef...@ha...>> 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 >>>>> Mat...@li... >>>>> <mailto:Mat...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Brian E. Granger >>>>> Cal Poly State University, San Luis Obispo >>>>> @ellisonbg on Twitter and GitHub >>>>> bgr...@ca... <mailto:bgr...@ca...> and >>>>> ell...@gm... <mailto:ell...@gm...> >>>>> >>>> >>>> >>> >>> >>> -- >>> Brian E. Granger >>> Cal Poly State University, San Luis Obispo >>> @ellisonbg on Twitter and GitHub >>> bgr...@ca... and ell...@gm... >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >> > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > @ellisonbg on Twitter and GitHub > bgr...@ca... and ell...@gm... > > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >