Currently matplotlib uses set_ and get_ functions for reading and writing values. However, since 2.6 python supports properties, which allow access to such values as attributes in addition to using the functions directly. Would it be worthwhile implementing property support in matplotlib?
This seems like a good candidate for a MEP. We'd want to take a graceful approach to transitioning to properties.
See here for information about MEPs:
Mike
···
On 01/16/2013 02:42 PM, Todd wrote:
Currently matplotlib uses set_ and get_ functions for reading and writing values. However, since 2.6 python supports properties, which allow access to such values as attributes in addition to using the functions directly. Would it be worthwhile implementing property support in matplotlib?
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
This was actually discussed during a Birds of a Feather (BOF) meeting back in SciPy2012 (which John Hunter attended). I am definitely for the idea, but it is going to be a very painful and long deprecation process. A bit of background (at least, my understanding of it)…
In matlab, there is the setp and getp functions. With this, you can set and get properties of various graphing objects. It is this feature that John duplicated, and it is the organic growth from there is why we are where we are now.
Furthermore, for those who haven’t noticed, we have a strange “alias” feature. For example, one could set edgecolor, but also ec, to the same effect. In a lark, I decided to trace down this feature and, to my horror, discovered how it works. Believe it or not, the docstring for set_edgecolor (or get_edgecolor, I forget) mentions that “ec” is an alias, and there is code elsewhere that processes the docstrings, looking for mentions of aliases, and uses that to guide the setting of properties. Of course, don’t forget that sometimes we do the plural of a property name as well…
Rather than keeping these attributes as a part of the artist objects, I would rather encapsulate the artist properties using a new Properties class (maybe it subclasses from dict?). This would make it easier to apply/share properties between many objects, and be more future-proof.
My 2 cents,
Ben Root
···
On Wed, Jan 16, 2013 at 2:42 PM, Todd <toddrjen@…149…> wrote:
Currently matplotlib uses set_ and get_ functions for reading and writing values. However, since 2.6 python supports properties, which allow access to such values as attributes in addition to using the functions directly. Would it be worthwhile implementing property support in matplotlib?
mutually-exclusive.
···
On Wed, Jan 16, 2013 at 2:55 PM, Benjamin Root <ben.root@...553...> wrote:
On Wed, Jan 16, 2013 at 2:42 PM, Todd <toddrjen@...149...> wrote:
Currently matplotlib uses set_ and get_ functions for reading and writing
values. However, since 2.6 python supports properties, which allow access
to such values as attributes in addition to using the functions directly.
Would it be worthwhile implementing property support in matplotlib?This was actually discussed during a Birds of a Feather (BOF) meeting back
in SciPy2012 (which John Hunter attended). I am definitely for the idea,
but it is going to be a very painful and long deprecation process.Is there a reason we have to deprecate the current method? They are not
But, then what is the gain of switching to the properties approach? Properties allows you to clean up one’s API, and also enables code-execution upon get/sets. We don’t really have much of a need for the latter, except in a few places. I would see a move to properties as a way to clean up our API back to the just the getp() setp() approach for portability with matlab.
Note, I am a fan of moving to properties, but all of this will have to be thought-out.
Ben Root
···
On Wed, Jan 16, 2013 at 2:55 PM, Benjamin Root <ben.root@…272…553…> wrote:
On Wed, Jan 16, 2013 at 2:42 PM, Todd <toddrjen@…149…> wrote:
Currently matplotlib uses set_ and get_ functions for reading and writing values. However, since 2.6 python supports properties, which allow access to such values as attributes in addition to using the functions directly. Would it be worthwhile implementing property support in matplotlib?
This was actually discussed during a Birds of a Feather (BOF) meeting back in SciPy2012 (which John Hunter attended). I am definitely for the idea, but it is going to be a very painful and long deprecation process.
Is there a reason we have to deprecate the current method? They are not mutually-exclusive.
Currently matplotlib uses set_ and get_ functions for reading and writing values. However, since 2.6 python supports properties, which allow access to such values as attributes in addition to using the functions directly. Would it be worthwhile implementing property support in matplotlib?
This was actually discussed during a Birds of a Feather (BOF) meeting back in SciPy2012 (which John Hunter attended). I am definitely for the idea, but it is going to be a very painful and long deprecation process.
Is there a reason we have to deprecate the current method? They are not mutually-exclusive.
Also along these lines, it’s relatively easy to write a metaclass to make everything with an explicit set and get method have a property as well. It’s a bit on the magical side, but not too bad.
There are a few things that would have name clashes (e.g. ax.figure and ax.set_figure) but the vast majority of these would only require manual code tweaking and would not require an api change, as they already behave as the property would.
This way you could still have setp and the like along with the properties and avoid any depreciation. It also would only require minimal code changes (but significant documentation additions).
Just my two cents, anyway.
···
On Jan 16, 2013 2:05 PM, “Todd” <toddrjen@…149…> wrote:
On Wed, Jan 16, 2013 at 2:55 PM, Benjamin Root <ben.root@…553…> wrote:
On Wed, Jan 16, 2013 at 2:42 PM, Todd <toddrjen@…149…> wrote:
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only – learn more at:
http://p.sf.net/sfu/learnmore_122612
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
I have created a MEP on the subject, MEP13, and a new mailing list thread
to discuss it.
···
On Wed, Jan 16, 2013 at 2:52 PM, Michael Droettboom <mdroe@...31...> wrote:
This seems like a good candidate for a MEP. We'd want to take a
graceful approach to transitioning to properties.See here for information about MEPs:
Home · matplotlib/matplotlib Wiki · GitHub
Mike