set of classes supported is even further limitedinserting methods will break clients that are already using __setattr__ or __getattribute__ of their own worsethis scheme does not address the built-in operation attributes issue described in the prior sectionbecause __getattribute__ is also not run in these contexts in our caseif person had __str__ it would be run by print operationsbut only because it was actually present in that class as beforethe __str__ attribute would not be routed to the inserted __getattribute__ method generically--printing would bypass this method altogether and call the class' __str__ directly although this is probably better than not supporting operator overloading methods in wrapped object at all (barring redefinitionat least)this scheme still cannot intercept and validate __x__ methodsmaking it impossible for any of them to be private whether operator overloading methods should be private is another matterbut this structure precludes the possibility much worsebecause this nonwrapper approach works by adding __getattribute__ and __setattr__ to the decorated classit also intercepts attribute accesses made by the class itself and validates them the same as accesses made from outside in other wordsthe class' own method won' be able to use its private names eitherthis is showstopper for the insertion approach in factinserting these methods this way is functionally equivalent to inheriting themand implies the same constraints as our original privacy code to know whether an attribute access originated inside or outside the classour methods might need to inspect frame objects on the python call stack this might ultimately yield solution--implementing private attributes as properties or descriptors that check the stack and validate for outside accesses onlyfor example--but it would slow access furtherand is far too dark magic for us to explore here (descriptors seem to make all things possibleeven when they shouldn' !while interestingand possibly relevant for some other use casesthis method insertion technique doesn' meet our goals we won' explore this option' coding pattern further here because we will study class augmentation techniques in the next in conjunction with metaclasses as we'll see theremetaclasses are not strictly required for changing classes this waybecause class decorators can often serve the same role python isn' about control now that 've gone to such great lengths to implement private and public attribute declarations for python codei must again remind you that it is not entirely pythonic to add access controls to your classes like this in factmost python programmers will probably find this example to be largely or totally irrelevantapart from serving as demonstration of decorators in action most large python programs get by successfully without any such controls at all example"privateand "publicattributes