performswe' have to add code around each hardcoded stack operation in large systemthis update may be nontrivial work as we'll discuss in we may also decide to move stacks to -based implementationif they prove to be performance bottleneck as general rulehardcoded operations on built-in data structures don' support future migrations as well as we' sometimes like as we'll see laterbuilt-in types such as lists are actually class-like objects in python that we can subclass to customizetoo this might be only partial fixthoughunless we anticipate future changes and make instances of subclasswe may still have maintenance issue if we use built-in list operations directly and ever want to extend what they do in the future stack module of coursethe real solution to such code maintenance dilemmas is to encapsulate-that iswrap up--stack implementations behind interfacesusing python' code reuse tools as long as clients stick to using the interfaceswe're free to change the interfacesimplementations arbitrarily without having to change every place they are called let' begin by implementing stack as module containing python listplus functions to operate on itexample - shows one way to code this example - pp \dstruct\basic\stack py " shared stack modulestack [class error(exception)pass on first import local excsstack error def push(obj)global stack stack [objstack use 'globalto change add item to the front def pop()global stack if not stackraise error('stack underflow'top*stack stack return top def top()if not stackraise error('stack underflow'return stack[ raise local error remove item at front raise local error or let indexerror occur def empty()return not stack is the stack []def member(obj)return obj in stack item in stackdef item(offset)return stack[offsetindex the stack def length()return len(stacknumber entries def dump()print('stack data structures