This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Arfrever, Darren.Dale, asvetlov, benjamin.peterson, christopherthemagnificent, daniel.urban, docs@python, dsdale24, eric.araujo, eric.snow, ncoghlan, python-dev, r.david.murray, stutzbach
Date 2012-11-12.02:53:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1352688796.68.0.698120788773.issue16267@psf.upfronthosting.co.za>
In-reply-to
Content
It took me a while to get my brain back up to speed with the full rationale behind the current design (mostly by rereading the multitude of comment on #11610).

As Darren says, the main advantage of the current scheme is that the wrapper descriptors deliberately *don't* have any concept of abstract/non-abstract independent of the methods that make them up. So I think the main thing to do is change the documentation of the affected descriptors to be more explicit about the required order of the replacement decorators. Otherwise people are likely to map "abstractXmethod" to "@abstractmethod + @Xmethod" and write them in that order (which won't work).
History
Date User Action Args
2012-11-12 02:53:16ncoghlansetrecipients: + ncoghlan, benjamin.peterson, stutzbach, eric.araujo, Arfrever, r.david.murray, asvetlov, daniel.urban, christopherthemagnificent, docs@python, dsdale24, python-dev, eric.snow, Darren.Dale
2012-11-12 02:53:16ncoghlansetmessageid: <1352688796.68.0.698120788773.issue16267@psf.upfronthosting.co.za>
2012-11-12 02:53:16ncoghlanlinkissue16267 messages
2012-11-12 02:53:16ncoghlancreate