SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
(1)
Nov
(33)
Dec
(20)
2004 Jan
(7)
Feb
(44)
Mar
(51)
Apr
(43)
May
(43)
Jun
(36)
Jul
(61)
Aug
(44)
Sep
(25)
Oct
(82)
Nov
(97)
Dec
(47)
2005 Jan
(77)
Feb
(143)
Mar
(42)
Apr
(31)
May
(93)
Jun
(93)
Jul
(35)
Aug
(78)
Sep
(56)
Oct
(44)
Nov
(72)
Dec
(75)
2006 Jan
(116)
Feb
(99)
Mar
(181)
Apr
(171)
May
(112)
Jun
(86)
Jul
(91)
Aug
(111)
Sep
(77)
Oct
(72)
Nov
(57)
Dec
(51)
2007 Jan
(64)
Feb
(116)
Mar
(70)
Apr
(74)
May
(53)
Jun
(40)
Jul
(519)
Aug
(151)
Sep
(132)
Oct
(74)
Nov
(282)
Dec
(190)
2008 Jan
(141)
Feb
(67)
Mar
(69)
Apr
(96)
May
(227)
Jun
(404)
Jul
(399)
Aug
(96)
Sep
(120)
Oct
(205)
Nov
(126)
Dec
(261)
2009 Jan
(136)
Feb
(136)
Mar
(119)
Apr
(124)
May
(155)
Jun
(98)
Jul
(136)
Aug
(292)
Sep
(174)
Oct
(126)
Nov
(126)
Dec
(79)
2010 Jan
(109)
Feb
(83)
Mar
(139)
Apr
(91)
May
(79)
Jun
(164)
Jul
(184)
Aug
(146)
Sep
(163)
Oct
(128)
Nov
(70)
Dec
(73)
2011 Jan
(235)
Feb
(165)
Mar
(147)
Apr
(86)
May
(74)
Jun
(118)
Jul
(65)
Aug
(75)
Sep
(162)
Oct
(94)
Nov
(48)
Dec
(44)
2012 Jan
(49)
Feb
(40)
Mar
(88)
Apr
(35)
May
(52)
Jun
(69)
Jul
(90)
Aug
(123)
Sep
(112)
Oct
(120)
Nov
(105)
Dec
(116)
2013 Jan
(76)
Feb
(26)
Mar
(78)
Apr
(43)
May
(61)
Jun
(53)
Jul
(147)
Aug
(85)
Sep
(83)
Oct
(122)
Nov
(18)
Dec
(27)
2014 Jan
(58)
Feb
(25)
Mar
(49)
Apr
(17)
May
(29)
Jun
(39)
Jul
(53)
Aug
(52)
Sep
(35)
Oct
(47)
Nov
(110)
Dec
(27)
2015 Jan
(50)
Feb
(93)
Mar
(96)
Apr
(30)
May
(55)
Jun
(83)
Jul
(44)
Aug
(8)
Sep
(5)
Oct
Nov
(1)
Dec
(1)
2016 Jan
Feb
Mar
(1)
Apr
May
Jun
(2)
Jul
Aug
(3)
Sep
(1)
Oct
(3)
Nov
Dec
2017 Jan
Feb
(5)
Mar
Apr
May
Jun
Jul
(3)
Aug
Sep
(7)
Oct
Nov
Dec
2018 Jan
Feb
Mar
Apr
May
Jun
Jul
(2)
Aug
Sep
Oct
Nov
Dec
S M T W T F S


1
2
(1)
3
4
5
6
7
(13)
8
(3)
9
(5)
10
(3)
11
(2)
12
13
14
(3)
15
(1)
16
(27)
17
(3)
18
19
20
21
(2)
22
23
(1)
24
25
(1)
26
(1)
27
(6)
28
(2)
29
30
(1)
31
(1)


Showing 1 results of 1

From: Benjamin R. <ben...@ou...> - 2013年01月23日 14:57:25
On Thu, Jan 17, 2013 at 6:33 AM, Todd <tod...@gm...> wrote:
> On Thu, Jan 17, 2013 at 11:30 AM, Todd <tod...@gm...> wrote:
>
>> On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson <pel...@gm...>wrote:
>>
>>> Hi Todd,
>>>
>>> I agree with the principle of properties - it will make much of the mpl
>>> codebase (and user code) more pythonic, so thanks for proposing this.
>>>
>>> Would you be able to give an example of how you propose setters such as
>>> Axes.set_xlim might make use of properties. The particular example I
>>> have picked uses keywords to determine the behaviours of the method itself:
>>>
>>> def set_xlim(self, left=None, right=None, emit=True, auto=False, **kw):
>>> ...
>>>
>>>
>>> For me, the backwards compatibility issue is the key blocker to this
>>> MEP. Would you mind providing some concrete examples (perhaps using the
>>> set_xlim method as a focus point)?
>>>
>>> Cheers,
>>>
>>> Phil
>>>
>>>
>> Methods like that will be a problem. I see two possible approaches
>> (which are not mutually exclusive):
>>
>> 1. keep the set_xlim method for more sophisticated cases.
>> 2. split the set_xlim method into several methods
>>
>> Frankly I am not sure deprecating the existing setter and getter methods
>> is really called for. It may not be worth the trouble for users. That is
>> why I said everything in the MEP is very tentative.
>>
>> For approach 1, we would keep the current method, but also have another
>> method:
>>
>> @xlim.setter
>> def xlim(self, lims):
>> ...
>>
>> so for the basic case, just setting the lims, you would do:
>>
>> axesobj.xlims = (leftval, rightval)
>>
>> For approach 2, you would have additionally have (there is already an
>> autoscale_x_on method):
>>
>> @autoscale_x.setter
>> def autoscale_x(self, auto):
>> ...
>>
>>
>> @emit_xlim.setter
>> def emit_xlim(self, emit):
>> ...
>>
>>
>> @xlim_left.setter
>> def xlim_left(self, left):
>> ...
>>
>>
>> @xlim_right.setter
>> def xlim_right(self, rigth):
>> ...
>>
>> (or you could do some python-fu to allow you to assign values to the
>> xlim[0] and xlim[1])
>>
>> This would require setting three separate attributes. However, we would
>> already have the autoscale_x property.
>>
>> In my opinion breaking up the API into separate calls would be a cleaner
>> approach anyway. Setters and getters should be setters and getters, they
>> shouldn't be modifying other unrelated values. But that does not mean we
>> have to remove the existing approach.
>>
>>
>>
>>
>
> I've added examples of two examples of difficult cases to the MEP. I've
> also added more specific details of how to deal with them.
>
> The MEP is still written under the assumption that we will ultimately
> deprecate the existing setter and getter methods but, as I said, whether
> this is the best approach is highly questionable.
>
>
My take is that things like xlims, titles and such probably shouldn't be
made into properties quite yet. They are more complex beasts. I am more
concerned about the simplification of the API w.r.t. the attributes of the
artist objects such as edgecolor, linewidth, facecolor, fontsize, etc....
It is these things down at the OO level that feels very klunky.
Cheers!
Ben Root

Showing 1 results of 1

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /