and against constructor functions in classes--prior to the introduction of __init__ methodsprogrammers achieved the same effect by running an instance through method manually when creating it ( =class(init()over timethoughdespite being fundamentally stylistic choicethe __init__ syntax came to be universally preferred because it was more explicitconsistentand maintainable although you should be the judgedecorators seem to bring many of the same assets to the table managing functions and classes directly most of our examples in this have been designed to intercept function and instance creation calls although this is typical for decoratorsthey are not limited to this role because decorators work by running new functions and classes through decorator codethey can also be used to manage function and class objects themselvesnot just later calls made to them imaginefor examplethat you require methods or classes used by an application to be registered to an api for later processing (perhaps that api will call the objects laterin response to eventsalthough you could provide registration function to be called manually after the objects are defineddecorators make your intent more explicit the following simple implementation of this idea defines decorator that can be applied to both functions and classesto add the object to dictionary-based registry because it returns the object itself instead of wrapperit does not intercept later callsregistering decorated objects to an api from __future__ import print_function registry {def register(obj)registry[obj __name__obj return obj both class and func decorator add to registry return obj itselfnot wrapper @register def spam( )return( * spam register(spam@register def ham( )return( * @register class eggsdef __init__(selfx)self data * def __str__(self)return str(self data decorators eggs register(eggs