On Thu, Jan 5, 2012 at 3:18 PM, Ryan May <rma...@gmail.com> wrote:
> On Thu, Jan 5, 2012 at 2:59 PM, Daniel Hyams <dhy...@gmail.com> wrote:
> > Right, __slots__ is definitely not a good idea to use except in very
> > specific situations. I would strongly recommend against its usage here.
> >
> > http://groups.google.com/group/comp.lang.python/msg/0f2e859b9c002b28
>
> I see that now. I had seen __slots__ used in a namedtuple example (in
> the Python docs) and assumed it was a good idea. The same idea could
> be achieved by using an internal _fields list and overriding
> __getattr__ if the fixed list of attributes was deemed a useful
> feature.
>
> Ryan
>
> >
> >
> >
> > On Thu, Jan 5, 2012 at 3:50 PM, Eric Firing <efir...@hawaii.edu> wrote:
> >>
> >> On 01/05/2012 07:34 AM, Ryan May wrote:
> >> > On Thu, Jan 5, 2012 at 10:58 AM, Benjamin Root<ben.r...@ou.edu>
> wrote:
> >> >>
> >> >>
> >> >> On Thu, Jan 5, 2012 at 10:40 AM, Benjamin Root<ben.r...@ou.edu>
> wrote:
> >> >>>
> >> >>>
> >> >>>> At the very least, it would help in compartmentallizing all the
> >> >>>> possible
> >> >>>> drawing attributes that are common across all artists. Currently,
> I
> >> >>>> am
> >> >>>> envisioning using a defaultdict object (which was introduced in
> >> >>>> python 2.5)
> >> >>>> or subclassing from it. This might help in keeping compatibility
> >> >>>> with
> >> >>>> existing code. Subclassing would allow for modifying __get__ and
> >> >>>> __set__ to
> >> >>>> treat some elements like 'c' and 'color', 'lw' and 'linewidth' and
> so
> >> >>>> on as
> >> >>>> the same.
> >> >>
> >> >>
> >> >> Grrrr, in defaultdict(), the default_factory is called without
> >> >> arguments, so
> >> >> a factory can't be made to produce a default value for a given key,
> >> >> unless I
> >> >> resort to more hackary...
> >> >
> >> > Might be better to explicitly use properties for this rather than
> >> > overriding dict:
> >> >
> >> > class Style(object):
> >> > __slots__ = ('_lw')
> >> >
> >> > def __init__(self, lw=None):
> >> > self.lw = lw
> >> >
> >> > def _set_linewidth(self, lw):
> >> > self._lw = lw
> >> >
> >> > def _get_linewidth(self):
> >> > return self._lw
> >> >
> >> > lw = property(_get_linewidth, _set_linewidth)
> >> > linewidth = property(_get_linewidth, _set_linewidth)
> >> >
> >> > Declaring slots allows you to keep the available attributes to those
> >> > explicity listed. This way, you can't set a random (misspelled?)
> >> > attribute and wonder for hours why style.edgcolor = 'blue' doesn't
> >> > work.
> >>
> >> This seems useful, and may be OK for this application; but a little
> >> googling indicates that it is not really what __slots__ was intended
> >> for, it is at best controversial, and it should be used very sparingly
> >> and carefully.
> >>
> >> Eric
> >>
> >> >
> >> > Ryan
> >> >
> >>
> >>
>
Some thoughts I have had while trying to tackle this problem:
1) Major difficulty is that different plotting functions currently have
different default values for various parameters. For example, spy() uses a
square marker by default. Furthermore, there are differences in how
plotting functions determine default-ness.
1.1 - call signature uses **kwarg
Therefore, if something like 'c' is in kwarg, then it gets popped and
used. If not, then sometimes a None is used which then means some sort of
default elsewhere, or a value from a cycle somewhere is extracted.
1.2 - call signature uses prop=None idiom
Therefore, it is impossible to know if the user explicitly wanted the
default property value or did not pass anything in.
1.3 - call signature explicitly sets a default (i.e., fmt="b-") in call
signature
This prevents being able to extract a default value from a rcparam unless
the user explicitly passes None. Therefore, it is difficult to have common
style across all plots with a common/similar function calls. Sometimes,
you explicitly pass None, sometimes you don't.
2) Plot property information being mixed in with the core process of
creating plot elements. This makes the process of making sure that all
desired properties are applied in a uniform and consistent manner. If each
function could break its job into two basic parts: create plot elements for
each dataset, apply style properties for each dataset plotted. In other
words, for creating a bar chart, the process should first create Rectangle
patches that places them at the correct locations and sized correctly
(information that is based entirely on the dataset), but they would have no
color, linewidth, hatch, etc. information yet. Then, styles are applied to
each before returning them to the user.
3) rcparam naming. I wanted to name things like "cycle.color" and
"cycle.marker", however, we currently have "axes.color_cycle". While I am
fine with continuing this naming convention, do we want to codify a set of
naming rules for future additions, or can they continue to be named anyway
we wish?
No matter how I look at this problem, we are looking at significant
behavioral changes and output results. This will likely have to be an
ongoing project and should probably be slated for a major version number
change (i.e., v2.0.0). One particular feature I am tinkering on is a
subclassed dict() that performs automatic translations of various property
names (i.e., style['c'] and style['color'] are both the same element) and
also performs fallbacks (i.e., if style['ec'] hasn't been set yet, then
retrieve style['c']). This object might then be the basis of holding the
core appearance information that is applied to the artist elements. Using
it, we can codify various behaviors with respect to default values,
rcparams and any other idiomatic things we have been doing.
For my own purposes, I am essentially continuing the current pattern for a
few more properties and trying to apply them to a few more functions.
However, because it breaks many things while continuing bad coding styles,
I doubt it should be marged into the official repos.
Cheers!
Ben Root
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
