{"id":8080,"date":"2021-01-24T19:24:10","date_gmt":"2021-01-24T13:54:10","guid":{"rendered":"http:\/\/www.pythonpool.com\/?p=8080"},"modified":"2026-07-13T12:31:33","modified_gmt":"2026-07-13T07:01:33","slug":"python__new__","status":"publish","type":"post","link":"https:\/\/www.pythonpool.com\/python__new__\/","title":{"rendered":"Python __new__: Control Object Creation Before __init__"},"content":{"rendered":"

Quick answer:<\/strong> Python calls __new__ to create or return an instance before __init__ initializes it. Override __new__ mainly for immutable subclasses, controlled instance reuse, or allocation decisions; otherwise ordinary __init__ construction is usually clearer.<\/p>\n

\"Python
Python calls __new__ to create or return an instance before __init__ initializes it; immutable types often need values set in __new__.<\/figcaption><\/figure>\n

__new__()<\/code> is the Python data model method that creates a new object. It runs before __init__()<\/code>. Most classes do not need to define it, because the inherited implementation from object<\/code> already creates a normal instance.<\/p>\n

The difference between __new__()<\/code> and __init__()<\/code> is simple but important. __new__()<\/code> allocates and returns the object. __init__()<\/code> receives that object and fills in starting state. If __new__()<\/code> does not return an instance of the class, Python may skip that class’s __init__()<\/code>.<\/p>\n

The official Python data model documents object.__new__()<\/a> and object.__init__()<\/a>. The Python tutorial on classes<\/a> gives broader object-oriented background, and the super()<\/a> reference explains cooperative parent calls.<\/p>\n

Use __new__()<\/code> only when object creation itself needs control. Common examples include immutable type subclasses, controlled caching, singleton-style objects, and advanced frameworks. For ordinary setup, prefer __init__()<\/code> because it is easier to read and less surprising.<\/p>\n

A correct __new__()<\/code> method is usually a @staticmethod<\/code>-like class method in practice: it receives cls<\/code>, calls super().__new__(cls)<\/code> or the parent type’s __new__()<\/code>, and returns the created object. The examples below keep that flow explicit.<\/p>\n

When reading code that defines __new__()<\/code>, ask two questions. First, does the method always return the kind of object callers expect? Second, can __init__()<\/code> still run safely after that return? Those questions catch most surprising bugs around caches, immutable values, and alternate object creation paths.<\/p>\n

Also remember that __new__()<\/code> is inherited. If a subclass overrides it, parent class behavior may still matter through super()<\/code>. Keep the method small and document the reason it exists, because future maintainers will naturally look for normal setup code in __init__()<\/code>.<\/p>\n

\n
\n

Contents<\/p>\nToggle<\/span><\/path><\/svg><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n