[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Change by Alexander Belopolsky : -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> datetime.py implementation of .replace inconsistent with C implementation ___ Python tracker

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Paul Ganssle added the comment: This issue was fixed in Python 3.7, and it turns out issue 31222 was a duplicate of it. It can be closed now. -- nosy: +p-ganssle ___ Python tracker

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

R. David Murray added the comment: By the way, when I say "again", I'm referring to the "return type of alternative constructors" thread: http://www.mail-archive.com/python-dev@python.org/msg92163.html This is effectively an extension of that discussion, because replace is an alternative

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

R. David Murray added the comment: Ah, interesting. The python version (which is based on the original python code that served as the specification for the C version) has docstrings that explicitly say "new XXX". The C docstrings and rest docs do not reflect that subtlety. The docstrings

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Eugene Toder added the comment: namedtuple._replace() actually doesn't call subclass' __new__. It calls tuple.__new__ directly, so it has the same problem as datetime classes. Parameter and Signature are new in 3.3. I'm not sure if they're expected to be used as base classes.

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Serhiy Storchaka added the comment: This looks as expected behavior to me. namedtuple._replace(), Parameter.replace(), Signature.replace() do it this way. -- ___ Python tracker

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Changes by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker ___ ___

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Eugene Toder added the comment: This seems like it can lead to even more subtle bugs when replace() is not overriden. Currently, any extra state in the subclass is left uninitialized, which usually leads to obvious breakage and is relatively easy to trace back to replace(). (I've done it

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

R. David Murray added the comment: Hmm. The contract is actually that replace returns a *new* instance with the specified values changed. So I think it would be adequate in this case to simply call the subclass constructor with the values that replace manages, and not worry about anything

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Eugene Toder added the comment: Yes, this is similar to my second approach. (You need to copy via __reduce__, because __copy__ my have been overriden to return self.) The general problem with it, is that if a subclass is designed to be immutable (probably a common case here), it may not

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

R. David Murray added the comment: Why can't you make a copy and then patch the changed attributes on the copy? -- ___ Python tracker ___

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Eugene Toder added the comment: Properly supporting subclasses in replace() is hard, at least without some cooperation from subclasses. For a proper replace() x.replace(a=newval).b == x.b should hold for every b not dependent on a, including ones added by subclasses. That is, it should

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

R. David Murray added the comment: To summarize, it looks like there are three issues here: (1) the python and C versions are out of sync behavior wise (the python should work like the C in this case, it seems) (2) there are some missing tests, since we are running the same tests against both

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Changes by R. David Murray : -- stage: -> needs patch type: -> behavior versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 ___ Python tracker

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Edward O added the comment: Here is a workaround for subclasses (23-compatible): --- start code --- class MyDate(datetime): @classmethod def fromDT(cls, d): :type d: datetime return cls(d.year, d.month, d.day, d.hour, d.minute, d.second, d.microsecond, d.tzinfo)

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Changes by Edward O edoubray...@gmail.com: -- nosy: +eddygeek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20371 ___ ___ Python-bugs-list mailing

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

New submission from Andrew Lutomirski: I'll admit that what I'm doing is possibly unhealthy. Nonetheless, I find this behavior *extremely* surprising. This code: --- start code --- import datetime class my_dt(datetime.datetime): def __new__(cls, *args, **kwargs): print('In

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Changes by Yury Selivanov yselivanov...@gmail.com: -- nosy: +belopolsky, yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20371 ___ ___

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Yury Selivanov added the comment: I've just quickly looked the issue: 1. There is an inconsistency between python c implementations: datetime.replace always returns datetime(...) object, but should return self.__class__() 2. new_datetime_ex in c implementation does not call constructors

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

R. David Murray added the comment: It is actually not surprising if you are familiar with the copy/pickle protocol. Presumably that should be mentioned in the replace docs, though (assuming I'm right and that is why the behavior occurs). -- nosy: +r.david.murray