Re: [matplotlib-devel] my $0.02 on MEP13
Indeed, good catch. But another issue comes to my mind: should ax1.title (that is, "ax1..title.__get__(ax1)" where ".." means no descriptor invoked) return a string (like now) or something that contains all the properties of the title? Returning a string copies the current behavior of get_title, but "ax2.title = ax1.title" would not do what I expect (I would expect every property related to the title to be copied). Now, if we want "ax2.title = ax1.title" to work as I expect (what do other people think here?), then there is no choice but to wrap the return value of __set__. Antony 2013/2/7 Erik Bray > On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee > wrote: > > Hi, > > > > I saw that a discussion started on transitioning to the use of properties > > instead of explicit getters and setters, which seems like a very good > idea > > to me... so I thought this would be a good idea to get involved in > > matplotlib-devel :) > > > > Right now an issue raised is what to do with set_* that take multiple > > arguments. Taking set_title, which takes both positional and keyword > > arguments, as an example, my idea would be to do > > > > ax.title = "A title" > > ax.title.fontdict = fontdict > > > > Basically, a property "foo" (in the matplotlib meaning of the word) > becomes > > a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword > > arguments to the old property setter become themselves descriptors on > that > > descriptor. > > Unfortunately descriptors don't really work like that, because when > you do `.title` on an instance that doesn't return the descriptor > itself, it just returns the result of `__get__` on the descriptor. So > in your example `.fontdict` would have to be an attribute on any > string assigned as the title. So what you really have to do for this > to work is to wrap every value returned by the descriptor in some kind > of proxy that adds the appropriate extra attributes. It also has to > do so in a way that the proxy can behave transparently like the > wrapped object, and that none of the wrapped objects attributes are > overshadowed. And it has to hypothetically work with instances any > any arbitrary type or class. > > While this is somewhat doable for a limited set cases it's really more > of a can of worms than it's worth. Believe me, I've tried to solve > similar problems to this one before. A couple easier solutions: Allow > the `.title` (and other such attributes) to be assigned to with a > (value, options) tuple where the value is the title itself, and the > options is a dictionary or tuple of supported options for the title. > Another solution is to just keep set_title() for cases like this if > one wishes to set the title with additional options (while still > allowing `.title = 'foo'` for the simple case). > -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
On Fri, Feb 8, 2013 at 10:04 AM, Antony Lee wrote: > 2013/2/7 Erik Bray > >> On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee >> wrote: >> > Hi, >> > >> > I saw that a discussion started on transitioning to the use of >> properties >> > instead of explicit getters and setters, which seems like a very good >> idea >> > to me... so I thought this would be a good idea to get involved in >> > matplotlib-devel :) >> > >> > Right now an issue raised is what to do with set_* that take multiple >> > arguments. Taking set_title, which takes both positional and keyword >> > arguments, as an example, my idea would be to do >> > >> > ax.title = "A title" >> > ax.title.fontdict = fontdict >> > >> > Basically, a property "foo" (in the matplotlib meaning of the word) >> becomes >> > a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword >> > arguments to the old property setter become themselves descriptors on >> that >> > descriptor. >> >> Unfortunately descriptors don't really work like that, because when >> you do `.title` on an instance that doesn't return the descriptor >> itself, it just returns the result of `__get__` on the descriptor. So >> in your example `.fontdict` would have to be an attribute on any >> string assigned as the title. So what you really have to do for this >> to work is to wrap every value returned by the descriptor in some kind >> of proxy that adds the appropriate extra attributes. It also has to >> do so in a way that the proxy can behave transparently like the >> wrapped object, and that none of the wrapped objects attributes are >> overshadowed. And it has to hypothetically work with instances any >> any arbitrary type or class. >> >> While this is somewhat doable for a limited set cases it's really more >> of a can of worms than it's worth. Believe me, I've tried to solve >> similar problems to this one before. A couple easier solutions: Allow >> the `.title` (and other such attributes) to be assigned to with a >> (value, options) tuple where the value is the title itself, and the >> options is a dictionary or tuple of supported options for the title. >> Another solution is to just keep set_title() for cases like this if >> one wishes to set the title with additional options (while still >> allowing `.title = 'foo'` for the simple case). >> > > Indeed, good catch. But another issue comes to my mind: should ax1.title > (that is, "ax1..title.__get__(ax1)" where ".." means no descriptor invoked) > return a string (like now) or something that contains all the properties of > the title? Returning a string copies the current behavior of get_title, > but "ax2.title = ax1.title" would not do what I expect (I would expect > every property related to the title to be copied). Now, if we want > "ax2.title = ax1.title" to work as I expect (what do other people think > here?), then there is no choice but to wrap the return value of __set__. > > Antony > > I think you are trying to make this too smart for its own good. I think things should work in a simple, consistent manner. If the property is set using a string, then it should return a string. If you assign a string to something, it should assign a string only. If you want to start copying other properties, we can use a separate property that accepts and returns a different object, which I am pretty sure was part of my proposal. This should be described in the documentation. So if you want the title fontdict, you get something like ax1.titletext.fontdict (where titletext is the property for a text object). Currently ax1.get_title returns a string, so ax2.set_title(ax1.get_title()) will only copy the string. If we want to change the defaults, so that the title-related methods work with text objects instead of strings, that is possible (although would be a major backwards-incompatible API break). But that is a separate discussion from MEP13, which only deals with the transition to properties. In all cases, under this proposal, I think properties should be kept as similar as possible to their setters and getters. API breaks should be a separate issue. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
On Fri, Feb 8, 2013 at 3:38 AM, Jason Grout wrote: > On 2/7/13 8:08 PM, Erik Bray wrote: > > A couple easier solutions: Allow > > the `.title` (and other such attributes) to be assigned to with a > > (value, options) tuple where the value is the title itself, and the > > options is a dictionary or tuple of supported options for the title. > > Interesting. Just brainstorming here...then > > ax.title += (None, moreoptions) > > could set more options (without changing the title text or already set > options), or > > ax.title -= (None, deleteoptions) > > could reset just certain options to default values. > > Thanks, > > Jason > I am not a fan of this approach. It seems to be trying to force a property to behave like a function when it isn't meant to behave like a function. In my mind a property is just that, a single aspect of an object. If you want to change another aspect, you need to change another property. So these "moreoptions" need to have their own properties, either in the axes object or, better yet, since they are properties of the title text, have them as properties of a text object. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
On Fri, Feb 8, 2013 at 2:40 AM, Antony Lee wrote: > Hi, > > I saw that a discussion started on transitioning to the use of properties > instead of explicit getters and setters, which seems like a very good idea > to me... so I thought this would be a good idea to get involved in > matplotlib-devel :) > > Right now an issue raised is what to do with set_* that take multiple > arguments. Taking set_title, which takes both positional and keyword > arguments, as an example, my idea would be to do > > ax.title = "A title" > ax.title.fontdict = fontdict > > Basically, a property "foo" (in the matplotlib meaning of the word) > becomes a descriptor with __get__ => get_foo and __set__ => set_foo, and > keyword arguments to the old property setter become themselves descriptors > on that descriptor. > > Antony > > I think this makes it over-complicated. It is much simpler, more explicit, and more consistent to have two properties here, one that only deals with a string, and a second that only deals with a text object. Then you can do something like (where titletext returns the text object): ax.titletext.fontdict That way we automatically get what you want without any additional work or fancy tricks in a much cleaner, more explicit, and more predictable manner. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
Just a crazy thought, but why are we trying to treat "title" and such as properties? When I think of properties for matplotlib, I think of edgecolors, fontsize, and linestyles. Why don't we solve that problem first? Cheers! Ben Root -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
Yes, I realize that this (or the += approach) was overdoing it. Separating the stuff in two different properties is probably more the way to go (at least, it's less crazy). Even the ax.title += (string, options) approach has the problem that this would imply ax.title (in the sense of ax.__dict__["title"].__get__(ax)) cannot be a string anymore, so this would involve some wrapper object. Ugh. Antony 2013/2/8 Todd > On Fri, Feb 8, 2013 at 2:40 AM, Antony Lee wrote: > >> Hi, >> >> I saw that a discussion started on transitioning to the use of properties >> instead of explicit getters and setters, which seems like a very good idea >> to me... so I thought this would be a good idea to get involved in >> matplotlib-devel :) >> >> Right now an issue raised is what to do with set_* that take multiple >> arguments. Taking set_title, which takes both positional and keyword >> arguments, as an example, my idea would be to do >> >> ax.title = "A title" >> ax.title.fontdict = fontdict >> >> Basically, a property "foo" (in the matplotlib meaning of the word) >> becomes a descriptor with __get__ => get_foo and __set__ => set_foo, and >> keyword arguments to the old property setter become themselves descriptors >> on that descriptor. >> >> Antony >> >> > I think this makes it over-complicated. It is much simpler, more > explicit, and more consistent to have two properties here, one that only > deals with a string, and a second that only deals with a text object. Then > you can do something like (where titletext returns the text object): > > ax.titletext.fontdict > > That way we automatically get what you want without any additional work or > fancy tricks in a much cleaner, more explicit, and more predictable manner. > > > > -- > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Errorbar problem?
Hi,
I think I have a problem with errorbars in a log plot. The problem is
reproducible through the enclosed errorbar_log.py file. As you can see I
plot a point with y = 10**(-5) and I want the errorbars drawn from
10**(-5.5) to 10**(-4.5) which should be symmetric in this plot but isn't.
Here is the content of my errorbar_log.py file:
#!/usr/bin/python
import numpy as np
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(111)
x = 0.0
y = 10**(-5.0)
yerr_low = 10**(-5.5)
yerr_upp = 10**(-4.5)
ax.errorbar(x,y,yerr=[[yerr_low],[yerr_upp]],fmt='o',markersize=4)
ax.set_xlim(-1.0,1.0)
ax.set_ylim(1E-6,1E-3)
ax.set_yscale('log')
plt.savefig('errorbar.png')
-
10**(-5.5) = 3.162277660168379e-06
and 10**(-4.5) = 3.1622776601683795e-05
but you can see that the lower boundary is not at the calculated value.
Do I misunderstand the behaviour of the errorbar function or is this a bug?
Cheers,
Markus
--
View this message in context:
http://matplotlib.1069221.n5.nabble.com/Errorbar-problem-tp40412.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Errorbar problem?
The bar is drawn from `y - yerr_low` to `y + yerr_upp`
ax.errorbar(x + .5,y,yerr=[[y - yerr_low],[yerr_upp -
y]],fmt='s',markersize=4)
will get you what you want.
Tom
On Fri, Feb 8, 2013 at 8:41 PM, Markus Haider wrote:
> Hi,
>
> I think I have a problem with errorbars in a log plot. The problem is
> reproducible through the enclosed errorbar_log.py file. As you can see I
> plot a point with y = 10**(-5) and I want the errorbars drawn from
> 10**(-5.5) to 10**(-4.5) which should be symmetric in this plot but isn't.
>
> Here is the content of my errorbar_log.py file:
>
> #!/usr/bin/python
> import numpy as np
> import matplotlib.pyplot as plt
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
> x = 0.0
> y = 10**(-5.0)
> yerr_low = 10**(-5.5)
> yerr_upp = 10**(-4.5)
> ax.errorbar(x,y,yerr=[[yerr_low],[yerr_upp]],fmt='o',markersize=4)
> ax.set_xlim(-1.0,1.0)
> ax.set_ylim(1E-6,1E-3)
> ax.set_yscale('log')
> plt.savefig('errorbar.png')
>
> -
>
> 10**(-5.5) = 3.162277660168379e-06
> and 10**(-4.5) = 3.1622776601683795e-05
>
> but you can see that the lower boundary is not at the calculated value.
>
>
>
> Do I misunderstand the behaviour of the errorbar function or is this a bug?
>
> Cheers,
> Markus
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/Errorbar-problem-tp40412.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
> --
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Thomas Caswell
[email protected]
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
