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
