[issue11610] Improving property to accept abstract methods
Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: FWIW, if you still want to advance this, you could bring it up on Python-dev. I still feel uncomfortable with the API but could be convinced with others thought it was the best solution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: Thank you for the suggestion. I will follow up at python-dev, but it will probably be a few weeks before I have time to do a proper job of it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Ned Deily n...@acm.org: -- nosy: -ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: Is there anything preventing this patch from being merged? -- nosy: +Darren.Dale ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: Is there anything preventing this patch from being merged? I have to make time to think about the API a bit more. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 12:20 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: Is there anything preventing this patch from being merged? I have to make time to think about the API a bit more. Ok. Maybe you will come up with another alternative that hadn't occurred to me. But I have given this issue quite a bit of thought, considered several alternatives, and felt fortunate to find a solution that preserves backwards compatibility, supports the property decorator syntax, and meshes well with the existing syntax for abstract methods. Perhaps, if you shared your concerns, I could help address them and maybe save you some time. Darrren -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? Darren -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. I'm not suggesting that it tag methods it receives as abstract. @getter/setter/deleter would still act the same. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. Why not? You could set the __abstractmethod__ attribute in abstractgetter(). This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? I find it produces a rather unfortunate ordering dependency for the decorators which is hard to remember. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. I'm not suggesting that it tag methods it receives as abstract. @getter/setter/deleter would still act the same. I wasn't talking about @getter/setter/deleter. I tried to be clear that I was talking about the abstractproperty() constructor. It doesn't currently tag the methods it receives as abstract, and to change this would be a backward incompatible change. Therefore, @abstractmethod should be used to tag methods as abstract before passing them to the abstractproperty() constructor, and the abc documentation should be changed to reflect this. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. Why not? You could set the __abstractmethod__ attribute in abstractgetter(). I was not talking about decorating before passing @abstractgetter. I was talking about decorating before passing to the abstractproperty() constructor. This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? I find it produces a rather unfortunate ordering dependency for the decorators which is hard to remember. Why is it difficult to remember that you need to tag a method as abstract before passing it to the property? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: Okay: how about this. We retain the passing of @abstractmethod to abstractpropert(), but @abstractgetter decorates the method for you. 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. I'm not suggesting that it tag methods it receives as abstract. @getter/setter/deleter would still act the same. I wasn't talking about @getter/setter/deleter. I tried to be clear that I was talking about the abstractproperty() constructor. It doesn't currently tag the methods it receives as abstract, and to change this would be a backward incompatible change. Therefore, @abstractmethod should be used to tag methods as abstract before passing them to the abstractproperty() constructor, and the abc documentation should be changed to reflect this. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. Why not? You could set the __abstractmethod__ attribute in abstractgetter(). I was not talking about decorating before passing @abstractgetter. I was talking about decorating before passing to the abstractproperty() constructor. This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? I find it produces a rather unfortunate ordering dependency for the decorators which is hard to remember. Why is it difficult to remember that you need to tag a method as abstract before passing it to the property? I don't think the common case should be passing things to abstractproperty(), rather using the decorator. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: Okay: how about this. We retain the passing of @abstractmethod to abstractpropert(), but @abstractgetter decorates the method for you. That can work, although I would advise against it. I find it strange that we would use @abstractmethod sometimes and not others. If that is what it takes to get the patch accepted, so be it. But since I don't understand the motivation behind this approach, I won't be the one to document the special cases of when @abstractmethod is required and when it is not. 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. I'm not suggesting that it tag methods it receives as abstract. @getter/setter/deleter would still act the same. I wasn't talking about @getter/setter/deleter. I tried to be clear that I was talking about the abstractproperty() constructor. It doesn't currently tag the methods it receives as abstract, and to change this would be a backward incompatible change. Therefore, @abstractmethod should be used to tag methods as abstract before passing them to the abstractproperty() constructor, and the abc documentation should be changed to reflect this. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. Why not? You could set the __abstractmethod__ attribute in abstractgetter(). I was not talking about decorating before passing @abstractgetter. I was talking about decorating before passing to the abstractproperty() constructor. This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? I find it produces a rather unfortunate ordering dependency for the decorators which is hard to remember. Why is it difficult to remember that you need to tag a method as abstract before passing it to the property? I don't think the common case should be passing things to abstractproperty(), rather using the decorator. It definitely is a common case, and always will be. You can't begin using abstractproperty.abstract(getter/setter/deleter) until you have an abstract property, which requires passing a (potentially abstract) method to the constructor. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: Okay: how about this. We retain the passing of @abstractmethod to abstractpropert(), but @abstractgetter decorates the method for you. That can work, although I would advise against it. I find it strange that we would use @abstractmethod sometimes and not others. If that is what it takes to get the patch accepted, so be it. But since I don't understand the motivation behind this approach, I won't be the one to document the special cases of when @abstractmethod is required and when it is not. It would just be a convenience. It definitely is a common case, and always will be. You can't begin using abstractproperty.abstract(getter/setter/deleter) until you have an abstract property, which requires passing a (potentially abstract) method to the constructor. What about @abstractproperty def something(): pass @abstractproperty.setter def set(): pass @abstractproperty.deleter def delete: pass requires you to pass a method (explicitly) to a constructor? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 6:24 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: It definitely is a common case, and always will be. You can't begin using abstractproperty.abstract(getter/setter/deleter) until you have an abstract property, which requires passing a (potentially abstract) method to the constructor. What about @abstractproperty def something(): pass @abstractproperty.setter def set(): pass @abstractproperty.deleter def delete: pass requires you to pass a method (explicitly) to a constructor? @abstractproperty def something(): pass takes the something function and passes it to the abstractproperty() constructor. It doesn't appear that you are familiar with how the decorator syntax works for properties. Here is how your example should probably look: @abstractproperty def something(): pass @something.setter def something(): pass @something.deleter def something(): pass -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: It just occurred to me, there is a potential problem with abstractproperty and the decorator syntax in my patch: class Foo: @abstractproperty def p(self): pass # p is abstract, but has no abstract methods @p.setter def p(self, val): pass # p has no abstract properties, at this point it becomes an instance # of property, not abstractproperty @p.deleter @abstractmethod def p(self): pass # the deleter was tagged as abstract, but p was already a # regular property. There is no way to turn a regular # property into an abstractproperty, so the abstractedness # of the deleter is not respected. Really, the ideal approach is the original one: provide the builtin property with an __isabstractmethod__ attribute, which is set to True if the property has any abstract methods, and False otherwise. (My C is probably too weak to modify the property builtin on my own). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: So, are there objections to this patch, or can it be merged? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: I have an idea. How about instead of reusing abstractmethod for abstract getters and setters, you add abstractproperty.abstractgetter/setter/deleter? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: Benjamin: have you thought this idea through? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: 2011/3/29 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: Benjamin: have you thought this idea through? Perhaps inadequately? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment:
I see some problems with this approach, but maybe I haven't fully appreciated
it. Let me summarize the goals and constraints as I see them:
1) compatible with long-form and decorator syntax of {abstract}property
declaration
2) backwards compatible, no change in semantics/behavior
3) decorator syntax needs to yield a concrete property once all abstract
methods associated with the abstract property have been replaced with concrete
implementations. (This is the reason why each abstract method associated with
the property needs to get tagged with __isabstractmethod__. It provides an
accounting of abstract methods associated with the property which fits with the
existing semantics of abstract method declaration.)
The current approach actually satisfies all of the goals and constraints. It
fits well with the existing semantics, there are no surprises and no changes in
behavior for any existing code. It is even compatible with anyone who may have
used @abstractmethod to decorate methods destined to be passed to
@abstractproperty using the long-form property declaration (which would have
worked even though it was not documented!)
The benefit of abstractproperty.abstract{...} is that one decorator is required
instead of two, right? Are there others?
It is true that one could define abstract{getter,setter,deleter} decorators
that would take care of setting the __isabstractmethod__ attribute on the
function received, so that the @abstractmethod decorator would not be needed
*once the property has been created*.
But if @abstractmethod is discouraged in favor of
abstractproperty.abstractgetter and friends, abstractproperty would have to tag
each method passed to its constructor as abstract (in order to support the
long-form syntax and also the initial declaration with the decorator syntax)
which would actually be a change in behavior with potential consequences. For
example, maybe a third party defined a concrete getter in an abstract base
class, and python-3.3 can't instantiate the subclasses because that getter was
automatically tagged as abstract by the new abstractproperty constructor. So
@abstractmethod would still be needed for methods passed to the constructor,
meaning sometimes @abstractmethod would be needed, and sometimes it would not.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11610
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment:
2011/3/29 Darren Dale rep...@bugs.python.org:
Darren Dale dsdal...@gmail.com added the comment:
I see some problems with this approach, but maybe I haven't fully appreciated
it. Let me summarize the goals and constraints as I see them:
1) compatible with long-form and decorator syntax of {abstract}property
declaration
2) backwards compatible, no change in semantics/behavior
3) decorator syntax needs to yield a concrete property once all abstract
methods associated with the abstract property have been replaced with
concrete implementations. (This is the reason why each abstract method
associated with the property needs to get tagged with __isabstractmethod__.
It provides an accounting of abstract methods associated with the property
which fits with the existing semantics of abstract method declaration.)
The current approach actually satisfies all of the goals and constraints. It
fits well with the existing semantics, there are no surprises and no changes
in behavior for any existing code. It is even compatible with anyone who may
have used @abstractmethod to decorate methods destined to be passed to
@abstractproperty using the long-form property declaration (which would have
worked even though it was not documented!)
The benefit of abstractproperty.abstract{...} is that one decorator is
required instead of two, right? Are there others?
Mostly it doesn't create a weird asymmetry between a @abstractproperty
decorated function not needing @abstractmethod but
@someabstractprop.setter needing it.
It is true that one could define abstract{getter,setter,deleter} decorators
that would take care of setting the __isabstractmethod__ attribute on the
function received, so that the @abstractmethod decorator would not be needed
*once the property has been created*.
But if @abstractmethod is discouraged in favor of
abstractproperty.abstractgetter and friends, abstractproperty would have to
tag each method passed to its constructor as abstract (in order to support
the long-form syntax and also the initial declaration with the decorator
syntax) which would actually be a change in behavior with potential
consequences. For example, maybe a third party defined a concrete getter in
an abstract base class, and python-3.3 can't instantiate the subclasses
because that getter was automatically tagged as abstract by the new
abstractproperty constructor. So @abstractmethod would still be needed for
methods passed to the constructor, meaning sometimes @abstractmethod would be
needed, and sometimes it would not.
That's not true. The method could be tagged in @abstractgetter decorator.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11610
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment:
On Tue, Mar 29, 2011 at 9:31 PM, Benjamin Peterson
rep...@bugs.python.org wrote:
2011/3/29 Darren Dale rep...@bugs.python.org:
The benefit of abstractproperty.abstract{...} is that one decorator is
required instead of two, right? Are there others?
Mostly it doesn't create a weird asymmetry between a @abstractproperty
decorated function not needing @abstractmethod but
@someabstractprop.setter needing it.
Did you read the documentation I provided in the patch? There is no
asymmetry, the documentation and examples provided by previous python
releases are demonstrably inadequate. For example:
class AbstractFoo(metaclass=ABCMeta):
def get_bar(self): ...
def set_bar(self, val): ...
bar = abstractproperty(get_bar, set_bar)
The documentation indicates that a subclass will not be instantiable
until all of its abstract methods and properties are overridden. What
is abstract about the bar property? Was it the getter, setter, or
both, or neither? The answer is neither. A subclass can simply do:
class Foo(AbstractFoo):
bar = property(AbstractFoo.get_bar, AbstractFoo.set_bar)
and it is instantiable. On the other hand, for AbstractFoo to assert
that subclasses must provide concrete implementations of the get_bar
and set_bar methods, it must decorate get_bar and set_bar with
@abstractproperty. This is true for previous releases of python, the
documentation of abstractproperty in previous python releases is
simply incomplete. If a method is abstract, it needs to have an
__isabstractmethod__ attribute that is True, and @abstractmethod
provides the means of setting this attribute.
This patch simply extends abstractproperty so it can respect the
abstractedness of the methods assigned to it. If somebody defines an
ambiguous abstractproperty like my AbstractFoo example, they get the
same result with the patch as they did without: an abstract property
with two concrete methods (this is an unfortunate situation that
cannot be fixed without breaking backwards compatibility).
Therefore, there is no asymmetry between when @abstractmethod is
required and when it is not. If the *method* is abstract and must be
reimplemented by a subclass, @abstractmethod is required. Even for
methods that participate in property definitions, even with
=python-3.2.
It is true that one could define abstract{getter,setter,deleter} decorators
that would take care of setting the __isabstractmethod__ attribute on the
function received, so that the @abstractmethod decorator would not be needed
*once the property has been created*.
But if @abstractmethod is discouraged in favor of
abstractproperty.abstractgetter and friends, abstractproperty would have to
tag each method passed to its constructor as abstract (in order to support
the long-form syntax and also the initial declaration with the decorator
syntax) which would actually be a change in behavior with potential
consequences. For example, maybe a third party defined a concrete getter in
an abstract base class, and python-3.3 can't instantiate the subclasses
because that getter was automatically tagged as abstract by the new
abstractproperty constructor. So @abstractmethod would still be needed for
methods passed to the constructor, meaning sometimes @abstractmethod would
be needed, and sometimes it would not.
That's not true. The method could be tagged in @abstractgetter decorator.
I think you misunderstood my point. I agreed with you that it could be
tagged by @abstractgetter. It cannot be tagged by the constructor.
That is where an asymmetry would be introduced between when
@abstractmethod is needed (declare methods abstract before passing
them to the constructor) and when it would not be (passing methods to
abstractgetter which declares them abstract).
(By the way, in review of issue11610.patch, GVR said he thought I had
the right idea and that the backward compatibility goal was satisfied.
Some of these points were covered in that discussion.)
Darren
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11610
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment:
On Tue, Mar 29, 2011 at 10:24 PM, Darren Dale rep...@bugs.python.org wrote:
Darren Dale dsdal...@gmail.com added the comment:
On Tue, Mar 29, 2011 at 9:31 PM, Benjamin Peterson
rep...@bugs.python.org wrote:
2011/3/29 Darren Dale rep...@bugs.python.org:
The benefit of abstractproperty.abstract{...} is that one decorator is
required instead of two, right? Are there others?
Mostly it doesn't create a weird asymmetry between a @abstractproperty
decorated function not needing @abstractmethod but
@someabstractprop.setter needing it.
Did you read the documentation I provided in the patch? There is no
asymmetry, the documentation and examples provided by previous python
releases are demonstrably inadequate. For example:
class AbstractFoo(metaclass=ABCMeta):
def get_bar(self): ...
def set_bar(self, val): ...
bar = abstractproperty(get_bar, set_bar)
The documentation indicates that a subclass will not be instantiable
until all of its abstract methods and properties are overridden. What
is abstract about the bar property? Was it the getter, setter, or
both, or neither? The answer is neither. A subclass can simply do:
class Foo(AbstractFoo):
bar = property(AbstractFoo.get_bar, AbstractFoo.set_bar)
and it is instantiable. On the other hand, for AbstractFoo to assert
that subclasses must provide concrete implementations of the get_bar
and set_bar methods, it must decorate get_bar and set_bar with
@abstractproperty.
Sorry, that should have read @abstractmethod.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11610
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Nick Coghlan ncogh...@gmail.com: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Ned Deily n...@acm.org added the comment: (Darren, I'm not sure why you are running into problems with that setup. I test with what sounds to be a very similar one including a MacPorts gettext port providing libintl although I do install ports as +universal (i386, x86_64) by default. And I don't know why you would have problems with _scproxy. If you would like to pursue, please open a separate issue with the results of your configure and make.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: Here is a new version of the patch. I think it addresses all of the issues that have been raised to date. I had to comment out the -lintl line in Modules/Setup to build on OS X, this seems to be a similar issue to http://bugs.python.org/issue6154 . So I don't have a _locale module, and I also don't have _scproxy. I ran make test, and get the same results with and without the patch: 315 passes, 22 failed, 15 skipped. All of the failures are due to missing _locale and _scproxy, with the exception of an error during the sax test that is unrelated to my changes. -- components: -Library (Lib) Added file: http://bugs.python.org/file21375/issue11610_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Ned Deily n...@acm.org added the comment: (Darren, what version of OS X and what arguments did you use for ./configure ? In general, for testing purposes, a vanilla ./configure with no args should work fine for building a Python that works right from your source build directory. If you want to build something to be installed, avoid using --enable-shared on OS X, see, for instance, Issue11445) -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: (Ned, I'm running 10.6.6 with a 64-bit kernel. I've tried running ./configure without any arguments, and also with --prefix=/opt/local, since I install essentially everything with MacPorts.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Daniel Urban urban.dani...@gmail.com added the comment: I tried to test your patch, but the build dies with this error: Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File .../cpython/Lib/io.py, line 60, in module Aborted I don't know why is this, but I get this error consistently with your patch, and no error without the patch. On Sat, Mar 19, 2011 at 22:13, dsdal...@gmail.com wrote: Thank you for the feedback. The reason I suggested deprecating abstractproperty is that I think it is essentially broken. Subclasses have to redeclare the entire property, and if they forget to declare the setter for what is supposed to be a read/write property, there is no way to catch it. With the new approach, it is possible to ensure that all the required features of the property have been implemented. ... On 2011/03/19 21:36:09, durban wrote: I don't think abstractproperty should be deprecated. It is still perfectly good to define a read-only abstract property (with one decorator instead of two). Zen of python. I'm guessing you're referring to There should be one-- and preferably only one --obvious way to do it. That is a good point. But currently the one way to: - create an abstract static method: @abstractstaticmethod - create an abstract class method: @abstractclassmethod - create an abstract property: @abstractproperty (as you pointed out, this has some problems) With your proposed change the one way to: - create an abstract static method: @abstractstaticmethod - create an abstract class method: @abstractclassmethod - create an abstract property: @abstractmethod + @property This is not a very good API. Note, that a similar thing could be done for class/staticmethod, and then using @abstractmethod + @classmethod would be possible, and the API would be more consistent. But it wasn't done because Guido objected it (see issue5867). This is the part where I am weak. Can you point me to documentation? Why is an exception check necessary? Do PyObject_IsTrue and Py_DECREF not know what to do when passed NULL? http://docs.python.org/dev/py3k/c-api/object.html#PyObject_GetAttrString If a Python API function returns NULL, that usually means that an exception was raised. If you don't want the exception to propagate, you should call PyErr_Clear. And I think it is not a good idea to call a function with NULL, unless the docs explicitly say that it can be passed NULL. -- components: +Interpreter Core ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sun, Mar 20, 2011 at 5:18 AM, Daniel Urban rep...@bugs.python.org wrote: Daniel Urban urban.dani...@gmail.com added the comment: I tried to test your patch, but the build dies with this error: Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File .../cpython/Lib/io.py, line 60, in module Aborted I don't know why is this, but I get this error consistently with your patch, and no error without the patch. On Sat, Mar 19, 2011 at 22:13, dsdal...@gmail.com wrote: Thank you for the feedback. The reason I suggested deprecating abstractproperty is that I think it is essentially broken. Subclasses have to redeclare the entire property, and if they forget to declare the setter for what is supposed to be a read/write property, there is no way to catch it. With the new approach, it is possible to ensure that all the required features of the property have been implemented. ... On 2011/03/19 21:36:09, durban wrote: I don't think abstractproperty should be deprecated. It is still perfectly good to define a read-only abstract property (with one decorator instead of two). Zen of python. I'm guessing you're referring to There should be one-- and preferably only one --obvious way to do it. That is a good point. But currently the one way to: - create an abstract static method: @abstractstaticmethod - create an abstract class method: @abstractclassmethod - create an abstract property: @abstractproperty (as you pointed out, this has some problems) With your proposed change the one way to: - create an abstract static method: @abstractstaticmethod - create an abstract class method: @abstractclassmethod - create an abstract property: @abstractmethod + @property This is not a very good API. Unlike methods, properties are composite objects. It is therefore reasonable that creating an abstract property might be a little different from creating an abstract method. Note, that a similar thing could be done for class/staticmethod, and then using @abstractmethod + @classmethod would be possible, and the API would be more consistent. But it wasn't done because Guido objected it (see issue5867). Thank you for pointing that out. I've followed up with him at python-ideas to seek clarification (he did not raise this point when I posted the change to descrobject.c) This is the part where I am weak. Can you point me to documentation? Why is an exception check necessary? Do PyObject_IsTrue and Py_DECREF not know what to do when passed NULL? http://docs.python.org/dev/py3k/c-api/object.html#PyObject_GetAttrString I'm familiar with that page. Do you know of any documentation addressing how to anticipate and respond to NULL? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: I think a better idea would be to override getter and friends on the abstractproperty class. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sun, Mar 20, 2011 at 12:19 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I think a better idea would be to override getter and friends on the abstractproperty class. I just suggested the same at python-ideas. I'll work on an alternate patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sun, Mar 20, 2011 at 5:18 AM, Daniel Urban rep...@bugs.python.org wrote: Daniel Urban urban.dani...@gmail.com added the comment: I tried to test your patch, but the build dies with this error: Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File .../cpython/Lib/io.py, line 60, in module Aborted I don't know why is this, but I get this error consistently with your patch, and no error without the patch. Have you added any print statements to the patch? I'm working on a completely new patch, which only touches abc.py on an existing python3.2 install. When I add a print statement to the abstract property creation routine, and run test_abc.py, I get the same error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: 2011/3/20 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sun, Mar 20, 2011 at 5:18 AM, Daniel Urban rep...@bugs.python.org wrote: Daniel Urban urban.dani...@gmail.com added the comment: I tried to test your patch, but the build dies with this error: Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File .../cpython/Lib/io.py, line 60, in module Aborted I don't know why is this, but I get this error consistently with your patch, and no error without the patch. Have you added any print statements to the patch? I'm working on a completely new patch, which only touches abc.py on an existing python3.2 install. When I add a print statement to the abstract property creation routine, and run test_abc.py, I get the same error. That's likely because the io library depends on abcs, so using print in them creates a dependency cycle. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: Thank you Daniel and Benjamin for the helpful feedback. I think the attached patch is a much better approach. It only touches abc.abstractproperty (instead of the builtin property), and uses a class method as a factory to return instances of either property or abstractproperty, depending on whether it holds any references to abstractmethods. The patch is backwards compatible with the existing (though in my opinion, still broken) syntax of passing concrete methods to the abstractproperty constructor. I say that syntax is broken because properties are composite objects, and it is the methods that inherently make a property abstract or concrete. If one passes concrete getters and setters to abstractproperty, how do we know when the property has become concrete? Thus, I changed the documentation to refer to the more robust approach of passing abstractproperty methods that have been decorated with abstractmethod. Unit tests are also provided. I still have not been able to build from my hg checkout, but I copied abc.py into my working 3.2 installation and ran the new test_abc.py without errors. I'll be happy to address any additional concerns. -- Added file: http://bugs.python.org/file21307/issue11610.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Darren Dale dsdal...@gmail.com: Removed file: http://bugs.python.org/file21293/property_with_abstractmethod.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Darren Dale dsdal...@gmail.com: Removed file: http://bugs.python.org/file21295/property_with_abstractmethod_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
New submission from Darren Dale dsdal...@gmail.com:
I posted a suggestion at python-ideas that the declaration of abstract
properties could be improved in such a way that they could be declared with
either the long-form or decorator syntax using the built-in property and
abc.abstractmethod:
{{{
class MyProperty(property):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
for f in (self.fget, self.fset, self.fdel):
if getattr(f, '__isabstractmethod__', False):
self.__isabstractmethod__ = True
break
class C(metaclass=ABCMeta):
@MyProperty
@abstractmethod
def x(self):
pass
@x.setter
@abstractmethod
def x(self, val):
pass
# this syntax would also be supported:
#@abstractmethod
#def getx(self):
#pass
#@abstractmethod
#def setx(self, val):
#pass
#x = MyProperty(getx, setx)
class D(C):
'D does not define a concrete setter and cannot be instantiated'
@C.x.setter
def x(self):
return 1
class E(D):
'E has a concrete getter and setter, and can be instantiated'
@D.x.setter
def x(self, val):
pass
}}}
It is hopefully evident that a relatively minor extension can be made to the
built-in property such that @abstractproperty would no longer be needed. I have
prepared a patch, complete with documentation and unit tests, but unfortunately
I have not been able to test it because I have not been able to build Python
from a mercurial checkout on either Ubuntu 11.04 or OS X 10.6.6 (for reasons
unrelated to the patch.) BDFL thought the idea sounded good for inclusion in
Python-3.3, and requested I submit the patch here.
--
components: Library (Lib)
files: property_with_abstractmethod.patch
keywords: patch
messages: 131436
nosy: dsdale24
priority: normal
severity: normal
status: open
title: Improving property to accept abstract methods
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21293/property_with_abstractmethod.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11610
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: The discussion on python-ideas: http://mail.python.org/pipermail/python-ideas/2011-March/009411.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Daniel Urban urban.dani...@gmail.com: -- nosy: +durban ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Daniel Urban urban.dani...@gmail.com added the comment: I looked at the patch (I didn't test it yet), my comments are on Rietveld. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: Here is a new patch that addresses a couple problems found in review: * Unit tests contained a typo (Property instead of property) * DeprecationWarning would be issued when importing abc rather than when creating abstractproperty. (whether abstractproperty should be deprecated has been questioned). -- Added file: http://bugs.python.org/file21295/property_with_abstractmethod_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
