python - 为什么 object.__new__ 在这两种情况下或者更确切地说是如何工作不同

Question

Python 版本:“'2.7.3(默认，2013 年 4 月 10 日，06:20:15)\n[GCC 4.6.3]'”

我有这个:

>>> class testclass1(object):
    ...     pass
    ... 

>>> class testclass2(object):
    ...     def __init__(self,param):
    ...             pass
    ... 

>>> a = object.__new__(testclass1, 56)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: object.__new__() takes no parameters

>>> b = object.__new__(testclass2, 56)

>>> b
    <__main__.testclass2 object at 0x276a5d0>

更多乐趣!对比上面testclass1的结果。

>>> class testclass3(object):
    ...     def __init__(self):
    ...             pass
    ... 

>>> c = object.__new__(testclass3, 56)

>>> c
    <__main__.testclass3 object at 0x276a790>

>>> c1 = object.__new__(testclass3)

>>> c1
    <__main__.testclass3 object at 0x276a810>

我的问题是如何(而不是为什么)object__new__ 在这两种情况下表现不同？另请注意，在第一种情况下，该错误有点误导，因为在第二种情况下，object.__new__ 确实以参数结束!

Answer 1

object.__new__ 和 object.__init__ 都经过精心构造的条件迷宫，在某些情况下允许过多参数，在其他情况下引发错误，并引发非常具体的警告。 The code that implements the checks很容易遵循，但如果没有 this elucidating comment，其背后的推理可能仍然难以理解:

You may wonder why object.__new__() only complains about argumentswhen object.__init__() is not overridden, and vice versa.

Consider the use cases:

1. When neither is overridden, we want to hear complaints about excess (i.e., any) arguments, since their presence could indicate there's abug.

2. When defining an Immutable type, we are likely to override only __new__(), since __init__() is called too late to initialize anImmutable object. Since __new__() defines the signature for thetype, it would be a pain to have to override __init__() just to stopit from complaining about excess arguments.

3. When defining a Mutable type, we are likely to override only __init__(). So here the converse reasoning applies: we don't wantto have to override __new__() just to stop it from complaining.

4. When __init__() is overridden, and the subclass __init__() calls object.__init__(), the latter should complain about excessarguments; ditto for __new__().

Use cases 2 and 3 make it unattractive to unconditionally check forexcess arguments. The best solution that addresses all four use casesis as follows: __init__() complains about excess arguments unless__new__() is overridden and __init__() is not overridden (IOW, if__init__() is overridden or __new__() is not overridden);symmetrically, __new__() complains about excess arguments unless__init__() is overridden and __new__() is not overridden (IOW, if__new__() is overridden or __init__() is not overridden).

However, for backwards compatibility, this breaks too much code.Therefore, in 2.6, we'll warn about excess arguments when bothmethods are overridden; for all other cases we'll use the above rules.