when __new__ is calledit normally constructs new instance of that class when we override itwe first check if our singleton instance has been createdif notwe create it using super call thuswhenever we call the constructor on oneonlywe always get the exact same instanceo oneonly( oneonly( = true the two objects are equal and located at the same addressthusthey are the same object this particular implementation isn' very transparentsince it' not obvious that singleton object has been created whenever we call constructorwe expect new instance of that objectin this casethat contract is violated perhapsgood docstrings on the class could alleviate this problem if we really think we need singleton but we don' need it python coders frown on forcing the users of their code into specific mindset we may think only one instance of class will ever be requiredbut other programmers may have different ideas singletons can interfere with distributed computingparallel programmingand automated testingfor example in all those casesit can be very useful to have multiple or alternative instances of specific objecteven though "normaloperation may never require one module variables can mimic singletons normallyin pythonthe singleton pattern can be sufficiently mimicked using module-level variables it' not as "safeas singleton in that people could reassign those variables at any timebut as with the private variables we discussed in objects in pythonthis is acceptable in python if someone has valid reason to change those variableswhy should we stop themit also doesn' stop people from instantiating multiple instances of the objectbut againif they have valid reason to do sowhy interfereideallywe should give them mechanism to get access to the "default singletonvaluewhile also allowing them to create other instances if they need them while technically not singleton at allit provides the most pythonic mechanism for singleton-like behavior