[WIP] Fixes #8113 : fix deprecation msg for attribute(property)#8122
[WIP] Fixes #8113 : fix deprecation msg for attribute(property)#8122Dorozhko-Anton wants to merge 2 commits intoscikit-learn:masterfrom Dorozhko-Anton:attribute_deprecation
Conversation
|
Yes, this is a bit hacky, but I don't mind it entirely. Doesn't work for |
|
In terms of properly wrapping a property, is |
|
So may be It is OK to make deeper introspection and compare name of the method with all properties' getters, setters, deleters. Then I have a question about warning message. Should I discriminate getter, setter and deleter in the deprecation message? Should it print out? |
|
no, Attribute x is deprecated will suffice.
…On 29 December 2016 at 20:51, Dorozhko Anton ***@***.***> wrote:
So may be It is OK to make deeper introspection and compare name of the
method with all properties' getters, setters, deleters. Then I have a
question about warning message. Should I discriminate getter, setter and
deleter in the deprecation message?
x = property(fget=deprecated("deprecated")(x_getter), fset=x_setter)
Should it print out?
Getter of Attribute x is deprecated; ...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8122 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEz6xhh9eEISXzyjZSKhs0LZSlsxlZnks5rM4K7gaJpZM4LWO11>
.
|
|
I have added comparison with setters, getters and deleters. But there is still problem with checking that f is method, because def ismethod(f):
spec = inspect.getargspec(f) //deprecated in python 3
return 'self' in spec.args |
|
My suggestion of using fget, etc. was in the case that we decorated the property ( |
|
Both part( i.e deprecated(property(funct.)) & property(deprecated(funct.)) ) have to be handled separately. Case 1. Case 2.
Notebook contain modified deprecation.py file and a test case |
|
Why do they both need to be handled?
…On 7 January 2017 at 23:53, akshay0724 ***@***.***> wrote:
Both part( i.e deprecated(property(funct.)) & property(deprecated(funct.))
) have to be handled separately.
Order of execution of both is reversed:
Case 1.
***@***.*** <https://github.com/property> @deprecated
<https://github.com/deprecated> Method()*
In this case first decorated class object is created,than it becomes
property.Object which is passed to __ call __(in class deprecated in
decorating.py) looks like a method.So this part should be handled in
_decorate_fun()(line 62 in decorating.py)
How to detect a method is property or not?
from args(passed to method) we can get self(i.e object of class) and from
that object through inspect module we can get all the property of that
class.Now we have to check if any function name in property(i.e fget, fset,
fdel) matches with with the name of function passed to decorator for ever
property. If match is found than it is a property otherwise a method.
Case 2.
***@***.*** <https://github.com/deprecated> @Property
<https://github.com/property> Method()*
In this case method get converted to property first and than deprecated
object is created. So object which is passed to decorator can be in
investigated at that time that it is a method or property in __ call __()
itself.
I have made changes to deprecation.py
1. *call*() method is modified so that it can check Case 2.
2. _decorate_property method is added to handle Case 2.
3. _decorate_fun is modified to handle Case1. as well as a normal
method.
Notebook <https://github.com/Akshay0724/soft/blob/master/Depricate.ipynb>
contain modified deprecation.py file and a test case
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8122 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEz6y59GSvmu-s4KcNtbZA8UF5pF82Pks5rP4rLgaJpZM4LWO11>
.
|
|
Well if we consider only one case and neglect the other than warning of one case will not look correct.Though both the order looks correct so we have to mention that which order to be followed while deprecating a property. |
|
This is merely a matter of providing a convention and expecting it to be
followed.
…On 8 January 2017 at 14:30, akshay0724 ***@***.***> wrote:
Well if we consider only one case and neglect the other than warning of
one case will not look correct.Though both the order looks correct so we
have to mention that which order to be followed while deprecating a
property.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8122 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEz6w8mDL5oqfWqmljehd-1kH0659Qcks5rQFg4gaJpZM4LWO11>
.
|
|
Deprecating a property in this way--- is analogous to case 1. of my previous comment.So this should be handled alone. Can I make a pull request handling this case? |
|
But why would we deprecate each of getter, setter, deleter? Usually we want
to deprecate an entire attribute. Deprecating just one of the accessors is
so uncommon that we don't need a decorator.
…On 8 January 2017 at 19:57, akshay0724 ***@***.***> wrote:
Deprecating a property in this way---
***@***.***(msg)
def getx(self):
print "Output: Deprecated Property fget"
return self.__x
@deprecated(msg)
def setx(self, value):
print "Output: Deprecated Property fset"
self.__x = value
@deprecated(msg)
def delx(self):
print "Output: Deprecated Property fdel"
del self.__x
Y = property(fget = getx,fset = setx,fdel = delx, doc = "I'm the 'Y' property.")`
is analogous to case 1. of my previous comment.So this should be handled
alone.
Can I make a pull request handling this case?
Thanks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8122 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEz68UNavaHkkvWp0H-pmZaZ8ZvmWF2ks5rQKTwgaJpZM4LWO11>
.
|
|
Sorry, I'd not understand what you are trying to say. I mean when we deprecate any one of getter,setter,deleter than how could the deprecated class be called when method other than the deprecated one is called. Or I think it is common to deprecate getter and warning would be shown only when it is used. |
|
Hello @jnothman, I have found a solution to your stated problem,by this solution we did not need to deprecate each of the accessors instead we can directly deprecate an attribute. By using builtins module in python we can explicitly write code for creating a attribute. So after writing that piece of code we can create an attribute in this way-- @property
@deprecated
def X():
def getx(self):
return self.x
def setx(self,x):
self.x=x
def delx(self):
del xPlease share your view about this approach. |
Reference Issue
Fixes #8113
What does this implement/fix? Explain your changes.
If deprecated function is attribute (
@property) then change message to"Attribute ... "To check if function is an attribute
self)Any other comments?
For now I avoid this #8113 (comment)
because I have not figured out how to wrap property object properly