Re: [Matplotlib-users] cycling mechanism
This is great! Absolutely a much-needed and much-requested feature. I wonder, however, about the need for function-specific color cycles. Is there a use case there? I'd be just as happy with a single global color cycle that all functions would use. I also like the suggestion of a "style" class that would store a bunch of drawing attributes on a single object. From that, a feature that might be nice would be the ability to pass "style='last'" (or something) to a plotting function and have it use the last style in the cycle again. This would allow one to draw (for example) a line and a bar plot that are related in the same color, and then draw another line and bar pair in a different color. But that's icing on top of the more important features you've already proposed. Mike On 01/04/2012 09:52 PM, Benjamin Root wrote: Hello all, So, I am getting to the point where I need to implement a color cycling mechanism throughout pyplot. So, before I get too deep in implementing it, I have some thoughts that I need feedback on. 1) Not all plotting functions use color cycling right now. Currently, only plot() and any function that calls plot in its process (such as errorbar()). Glaring omissions are bar() and scatter(), and pie() could also benefit from having a uniform cycling mechanism. So, the issue going forward is, do we want to enable common cycling for all the pyplot/axes plotting functions which would require updating the test images and break backwards compatibility (in a sense), or do we want to have a per-function default rcparams that would contain one-element cycles that would effectively maintain current drawing results? 2) I also have the need to implement line-style cycling for b&w publications. Of course if I implement that, then why not hatch-cycling? marker-cycling? I have seen use-cases for all of these, and I am considering how to have a generalized framework for this. So my question is, what attributes would we like to see cycle-able? Here is a short list and some usecases I have come up with. Please extend this with ideas of your own. color - plot(), errorbar(), scatter(), bar(), hist(), pie(), stem() linestyle - plot(), errorbar(), stem() hatch - bar(), hist(), pie() marker - plot(), errorbar(), scatter(), stem() linewidth? facecolor/edgecolor? joinstyle? 3) rcparam names. I was thinking about how to name these cycles in the matplotlibrc file. Possibly: cycle.colors cycle.linestyles cycle.hatches cycle.markers And these would represent the global default, meanwhile, function-specific cycles could be given by: cycle.colors.pie cycle.colors.bar cycle.linestyles.plot cycle.linestyles.errorbar I was thinking that in code, one would access the full name attribute for the function, and I would extend the __get__ function to intelligently fall back to the global default if the full-name attribute is not specified. However, would there be confusion in a situation such as a person who wanted to use barh() but only had specified cycle.colors.bar? 4) Ultimately, my goal is to be able to create some typical profiles that have useful cycle specs, and possibly make some available as convenience functions, such as a b&w mode. Such a mode would set the default colormap to a grayscale-friendly colorscale, and use line style, hatch and marker cycles instead of a full color cycle. Thoughts? Comments? 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 -- 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
Re: [Matplotlib-users] cycling mechanism
Just one quick thought. I hope that you will implement a longer default color cycle than the current default. I have several times run into situations where I have to either modify the cycle or specify the colors manually because I had more than 7 lines. Also, it'd be nice to have the colors be as distinguishable as possible (at least early in the cycle). I agree that having linestyle cycling as well would be nice, though it's difficult to imagine as many distinguishable line styles as colors, though there could certainly be more than the current 4. I wonder about a simple mechanism to opt for line style cycling rather than color cycling so as to produce black & white plots (as mentioned in another post). Jon > Hello all, > > So, I am getting to the point where I need to implement a color > cycling mechanism throughout pyplot. So, before I get too deep in > implementing it, I have some thoughts that I need feedback on. > > Thoughts? Comments? -- __ Jonathan D. Slavin Harvard-Smithsonian CfA jsla...@cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA __ -- 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
Re: [Matplotlib-users] cycling mechanism
On Thu, Jan 5, 2012 at 6:45 AM, Michael Droettboom wrote: > This is great! Absolutely a much-needed and much-requested feature. > > I wonder, however, about the need for function-specific color cycles. Is > there a use case there? I'd be just as happy with a single global color > cycle that all functions would use. > > There are two reasons I see for this. First, maintaining current behavior. For example, pyplot currently uses the same color regardless of the number of times a user calls scatter. That might be a feature for some, or at least, it would be undesired to change that for existing code. I don't know how strong this argument is, but I did not want to unilaterally make this change. Second, and possibly more strongly is the following two use-cases: for y1, y2 in zip(linedata, bardata) : plt.plot(x, y1) plt.bar(x, y2) and for y in linedata : plt.plot(x, y) for y in bardata : plt.bar(x, y) I would assume that in these cases, the user would expect that the line plot using y1 would have the same color as the bars using y2. Also, that the two figures would be identical. Implementation-wise, if there is a single color cycle object for these functions to draw from, then this can not be guaranteed without internally creating a per-function color-cycle objects. Once you are at that point, then it is only a short jump to just allowing users to specify per-function color-cycles anyway. I also like the suggestion of a "style" class that would store a bunch of > drawing attributes on a single object. > 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. > > From that, a feature that might be nice would be the ability to pass > "style='last'" (or something) to a plotting function and have it use the > last style in the cycle again. This would allow one to draw (for example) > a line and a bar plot that are related in the same color, and then draw > another line and bar pair in a different color. But that's icing on top of > the more important features you've already proposed. > Hmmm, this could possibly be a solution to avoid the problem I mention above. So, in the pyplot state-machine, there would not only be the cycle objects, but also a current style state that would not trigger a next() call on the cycles if the plotting function states that it wants the current style. Interesting... 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
Re: [Matplotlib-users] cycling mechanism
On Thu, Jan 5, 2012 at 7:56 AM, Jonathan Slavin wrote: > Just one quick thought. I hope that you will implement a longer default > color cycle than the current default. I have several times run into > situations where I have to either modify the cycle or specify the colors > manually because I had more than 7 lines. Once the framework is in-place, that is certainly possible. I agree that the current list is probably too short and could use 3 or 4 more values. > Also, it'd be nice to have > the colors be as distinguishable as possible (at least early in the > cycle). Agreed. Having blue and then green has always annoyed me. However, I am hardly a color expert, and I would greatly welcome input from the peanut gallery (possibly from the same people pushing for a change in the default colormap?) > I agree that having linestyle cycling as well would be nice, > though it's difficult to imagine as many distinguishable line styles as > colors, though there could certainly be more than the current 4. A new feature added in v1.1.0 was the ability to specify custom line styles, and a quick look through the line styles available in LibreOffice could be an inspiration for some more standard styles. > I wonder about a simple mechanism to opt for line style cycling rather > than color cycling so as to produce black & white plots (as mentioned in > another post). > The idea is that since these are all configurable through the rcparam mechanism, standard profiles can be created with various combinations of settings and all a user (or a convenience function) has to do is "matplotlibrc.update(mystyle_profile)". Note, this wouldn't be a "live" switch of styles. In other words, once an element has been plotted, changing the profile will not update those plot elements. 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
Re: [Matplotlib-users] cycling mechanism
On Thu, Jan 5, 2012 at 10:40 AM, Benjamin Root 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. >> > G, 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... 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
Re: [Matplotlib-users] cycling mechanism
On Thu, Jan 5, 2012 at 10:58 AM, Benjamin Root wrote:
>
>
> On Thu, Jan 5, 2012 at 10:40 AM, Benjamin Root 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.
>
>
> G, 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.
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
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
[Matplotlib-users] Caption in Plot Directive
Is this information incorrect? http://matplotlib.sourceforge.net/devel/documenting_mpl.html#module-matplotlib.sphinxext.plot_directive This line seems to preclude ever getting to the below code to process the caption. https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/sphinxext/plot_directive.py#L601 I think the proper fix is to make :caption: an option. Skipper -- 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
[Matplotlib-users] draw bbox around axes title
Hi,
I'm trying to draw a box around an axes title, and I'm having trouble
controlling it. I want the box to span the width of the x axis. I
tried some iterations on the below since xy and height/width are
hard-coded in set_title, but when I call show, it seems the width of
the box is reset. Any ideas? Thanks,
Skipper
import matplotlib as mpl
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(111, axisbg='lightgrey')
ax.set_ylim(-0.05,1.05)
ax.set_xlim(-0.5,9.5)
rd = np.random.dirichlet(np.ones(10))
ax.plot(np.arange(10), rd, 'bo', markersize=5)
ax.vlines(np.arange(10), 0 ,rd, color='b')
title_box = dict(boxstyle = "Round", fc='gray', ec='black')
ax.set_title("1", bbox = title_box, x=0, y=1)
bbox = ax.title._bbox_patch
bbox.update(dict(width=25.))
fig.suptitle("Dirichlet(1) Draw", fontsize=36)
fig.subplots_adjust(top=.85)
--
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
Re: [Matplotlib-users] cycling mechanism
On Thu, Jan 5, 2012 at 11:34 AM, Ryan May wrote:
> On Thu, Jan 5, 2012 at 10:58 AM, Benjamin Root wrote:
> >
> >
> > On Thu, Jan 5, 2012 at 10:40 AM, Benjamin Root 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.
> >
> >
> > G, 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.
>
> Ryan
>
>
This is actually a great idea. This codifies in stone the alternative
names of various properties. I have also taken this idea a step further.
Some getter functions, such as for facecolor, will return the value of
color if facecolor is None. This way, we can explicitly code the fallbacks
and relationships the properties have with each other. So far, I have:
'_c', '_ec', '_fc', '_hatch', '_ls', '_lw', '_marker', '_mec', '_mew',
'_mfc', '_mfca', '_ms'
The fallbacks are:
_ec --> _c
_fc --> _c
_mec --> _ec
_mew --> _lw
_mfc --> _fc
_mfca --> _mfc
Any other properties anybody can think of to add?
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
Re: [Matplotlib-users] cycling mechanism
On Thu, Jan 5, 2012 at 11:51 AM, Benjamin Root wrote: > > > On Thu, Jan 5, 2012 at 7:56 AM, Jonathan Slavin > wrote: > >> Just one quick thought. I hope that you will implement a longer default >> color cycle than the current default. I have several times run into >> situations where I have to either modify the cycle or specify the colors >> manually because I had more than 7 lines. > > > Once the framework is in-place, that is certainly possible. I agree that > the current list is probably too short and could use 3 or 4 more values. > > >> Also, it'd be nice to have >> the colors be as distinguishable as possible (at least early in the >> cycle). > > > Agreed. Having blue and then green has always annoyed me. However, I am > hardly a color expert, and I would greatly welcome input from the peanut > gallery (possibly from the same people pushing for a change in the default > colormap?) > I guess this is sort of a tangential discussion, but, since you mentioned it, I've attached a script showing my vote for a 11-color cycle. Also, I've attached a script which shows all named colors defined by mpl. -Tony example_color_cycle.py Description: Binary data show_named_colors.py Description: Binary data -- 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
Re: [Matplotlib-users] cycling mechanism
On 01/05/2012 07:34 AM, Ryan May wrote:
> On Thu, Jan 5, 2012 at 10:58 AM, Benjamin Root wrote:
>>
>>
>> On Thu, Jan 5, 2012 at 10:40 AM, Benjamin Root 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.
>>
>>
>> G, 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
>
--
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
Re: [Matplotlib-users] cycling mechanism
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
On Thu, Jan 5, 2012 at 3:50 PM, Eric Firing wrote:
> On 01/05/2012 07:34 AM, Ryan May wrote:
> > On Thu, Jan 5, 2012 at 10:58 AM, Benjamin Root wrote:
> >>
> >>
> >> On Thu, Jan 5, 2012 at 10:40 AM, Benjamin Root 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.
> >>
> >>
> >> G, 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
> >
>
>
>
> --
> 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
>
--
Daniel Hyams
dhy...@gmail.com
--
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
Re: [Matplotlib-users] cycling mechanism
On Thu, Jan 5, 2012 at 2:59 PM, Daniel Hyams 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 > > > Good to know. I haven't used slots regularly before and was unaware of the controversy around it. The good news is that the slots mechanism isn't critical to the Style() class anyway. What is more important is the use of properties and setting up the fallbacks. Heck, I am not entirely convinced that I would need to include the alternative spellings for the properties. 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
Re: [Matplotlib-users] cycling mechanism
On Thu, Jan 5, 2012 at 2:59 PM, Daniel Hyams 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 wrote:
>>
>> On 01/05/2012 07:34 AM, Ryan May wrote:
>> > On Thu, Jan 5, 2012 at 10:58 AM, Benjamin Root wrote:
>> >>
>> >>
>> >> On Thu, Jan 5, 2012 at 10:40 AM, Benjamin Root 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.
>> >>
>> >>
>> >> G, 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
>> >
>>
>>
>>
>> --
>> 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
>
>
>
>
> --
> Daniel Hyams
> dhy...@gmail.com
>
> --
> 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
>
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
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
[Matplotlib-users] Tkinter Scaling Problems
Hi, I'm trying to embed a Matplotlib graph along with the toolbar in my Tkinter application. The problem I'm facing is that when I maximize the application, the plot only fills the top half of the screen and the bottom half is taken up by the toolbar with a lot of whitespace. I based my code on the embedding_with_tk examples, and I've tried every layout combination with pack(), but I still can't get just the plot to take up all the space. This is the relevant code: f2 = Tkinter.Frame(n()) canvas = FigureCanvasTkAgg(f, master=f2) canvas.show() canvas.get_tk_widget().pack(side=Tkinter.TOP, fill=Tkinter.BOTH, expand=1) toolbar = NavigationToolbar2TkAgg(canvas, f2) toolbar.update() canvas._tkcanvas.pack(side=Tkinter.BOTTOM, fill=Tkinter.BOTH, expand=0) Any help would be welcome. Thanks, KK -- 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
