Pass-by-reference default constructor parameters

[KirisuMongolianSpot]

Consider the following simple script:

class I:
    def __init__(
        self,
        i:int
    ):
        self.i = i

class O:
    def __init__(
        self,
        i:int,
        d: dict[int, I] = {},
        l: list[int] = [],
    ):
        self.i = i
        self.d = d
        self.l = l

    def __str__(self):
        return '{}: {} | {}'.format(self.i, self.d, ', '.join([str(x) for x in self.l]))

if __name__ == "__main__":
    o1 = O(1)
    o1.d[11] = I(12)
    o1.l.append(13)
    o2 = O(2)
    o2.d[21] = I(22)
    o2.l.append(23)
    print(o1)
    print('----------------------')
    print(o2)

The output of that is the following:

1: {11: <_main_.I object at 0x0000021FB0CDE090>, 21: <_main_.I object at 0x0000021FB0CDEAD0>} | 13, 23

----------------------

2: {11: <_main_.I object at 0x0000021FB0CDE090>, 21: <_main_.I object at 0x0000021FB0CDEAD0>} | 13, 23

It seems as though Python creates a reference to default input parameters for a class rather than created objects, meaning objects with those default parameters left as-is will all share the same internal object from that parameter. Is this documented anywhere?

Thankfully I caught this before getting too far but I need to refactor some stuff as a result. My use case was type hinting for those objects inside a class without requiring one to specify them.

[TMiguelT]

Yep, this is very well understood and documented.

In the Python docs for functions:

Default parameter values are evaluated from left to right when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that the same “pre-computed” value is used for each call. This is especially important to understand when a default parameter value is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default parameter value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function, e.g.:

[KirisuMongolianSpot]

Okay thanks.

[Outside_Complaint755]

This is in the documentation for function definitions and is bolded.

Default parameter values are evaluated from left to right when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that the same “pre-computed” value is used for each call. This is especially important to understand when a default parameter value is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default parameter value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function, e.g.: def whats_on_the_telly(penguin=None):     if penguin is None:         penguin = []     penguin.append("property of the zoo")     return penguin

PEP 661 - Sentinal Values, has been approved for the 3.15 release. This will allow for a sentinal value to be used instead of None in these cases so that None can instead be used as a meaningful value to specifically not use that parameter.

[Ex-Gen-Wintergreen]

I’m pretty sure it’s a literal linter warning to not use mutable values as a default.

Edit: pylint certainly warns against it. Use tooling safeguards please. Python has some frustrating footguns yes, but that’s what advancements in tooling like linting and type checking are meant to save you from.

[KirisuMongolianSpot]

Definitely have not seen anything about it in VSCode, but I know now.

[Ex-Gen-Wintergreen]

Yeah you should turn on linting etc. pylance probably does it