yeslists are objects all that special non-object-oriented looking syntax we've been looking at for accessing lists or dictionary keyslooping over containersand similar tasks is actually "syntactic sugarthat maps to an object-oriented paradigm underneath we might ask the python designers why they did this isn' object-oriented programming always betterthat question is easy to answer in the following hypothetical exampleswhich is easier to readas programmerwhich requires less typingc add(bl[ setitem( [keyvalue setitem(keyvaluefor in alist#do something with it alist iterator(while it has_next() it next(#do something with the highlighted sections show what object-oriented code might look like (in practicethese methods actually exist as special double-underscore methods on associated objectspython programmers agree that the non-object-oriented syntax is easier both to read and to write yet all of the preceding python syntaxes map to objectoriented methods underneath the hood these methods have special names (with double-underscores before and afterto remind us that there is better syntax out there howeverit gives us the means to override these behaviors for examplewe can make special integer that always returns when we add two of them togetherclass sillyint(int)def __add__(selfnum)return this is an extremely bizarre thing to dograntedbut it perfectly illustrates these object-oriented principles in actiona sillyint( sillyint(