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
