Skip to content

Conversation

pganssle
Copy link
Member

@pganssle pganssle commented Oct 30, 2017

Per the discussion on the issue tracker, the behavior of the pure python implementation of datetime, date and time are out of whack with the equivalent from _datetimemodule.c. Since the C version is almost certainly what's being used almost everywhere, this shouldn't have any real behavioral changes. The equivalent bug in pypy3 has been fixed for some time.

https://bugs.python.org/issue31222

@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

@pganssle
Copy link
Member Author

I'll note that since there's no actual behavior change for the delivered binaries, it's not clear whether this requires a NEWS entry.

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I have a few comments.

@@ -828,7 +828,7 @@ def replace(self, year=None, month=None, day=None):
month = self._month
if day is None:
day = self._day
return date(year, month, day)
return type(self)(year, month, day)
Copy link
Member

@vstinner vstinner Oct 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer self.__class__, but I never know which one is the best :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have any real preference here. I usually go with self.__class__ myself, but I was somewhat persuaded by the discussion on StackOverflow that seemed to indicate that they are equivalent in Python 3, and that type is shorter - seemed like a mixed bag as to which one is more intuitive. I'm happy to change it to the "house style".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's even a relevant precedent, since they're in two different languages, but it does seem that the C source code uses Py_TYPE(self) rather than some equivalent of self.__class__. Though for all I know that's a macro that expands to self.__class__...

@@ -1520,6 +1520,13 @@ def test_replace(self):
base = cls(2000, 2, 29)
self.assertRaises(ValueError, base.replace, year=2001)

def test_subclass_replace(self):
class C(self.theclass):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind to rename the class to "DateSubclass" or anything longer than a single letter? :-) Same request for the class below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have particularly strong opinions on the naming here, I mainly used C because test_subclass_date and test_subclass_time both use C as their "in-function subclass", and there are already top-level SubclassTime/SubclassDate/SubclassDatetime classes that are used to run all or nearly all the tests again on a subclass (presumably to check that subclasses satisfy the same contract as the base class). I think DateSubclass might get confused with these other test classes.

Another alternative which avoids this question entirely is to replace the specific test_subclass_replace function with a test_replace_class function (which will automatically get the subclass check by virtue of the inheritance through TestSubclassDateTime). The main reasons I didn't do this are that 1. I think the logic is a bit clearer (why are you checking that .replace returns the same class as the object?) and 2. this way it automatically "recurses" the check such that it's clear that even subclasses retain this property. This is a fairly weakly-held opinion, though, and I'm willing to be changed.

If we do decide that renaming is best, would maybe _Subclass be a reasonable name?

@pganssle
Copy link
Member Author

pganssle commented Nov 5, 2017

I updated the subclass names to be somewhat more descriptive. I'm not sure if the bot is supposed to automatically update when my CLA goes through, but I've been told that the signed CLA I sent in has been processed.

The only remaining question is whether this needs a news item.

@@ -1520,6 +1520,13 @@ def test_replace(self):
base = cls(2000, 2, 29)
self.assertRaises(ValueError, base.replace, year=2001)

def test_subclass_replace(self):
class _DateSubclass(self.theclass):
Copy link
Member

@vstinner vstinner Nov 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove "_" prefix in class names. These classes are only defined in the scope of the test, no need to declare them as "private" with the "_" prefix.

@pganssle
Copy link
Member Author

pganssle commented Nov 9, 2017

This should be ready to go - any thoughts on whether it needs NEWS?

@vstinner vstinner merged commit 191e993 into python:master Nov 9, 2017
@vstinner
Copy link
Member

vstinner commented Nov 9, 2017

I merged your PR, thanks!

@miss-islington
Copy link
Contributor

Thanks @pganssle for the PR, and @Haypo for merging it 🌮🎉.. I'm working now to backport this PR to: 3.6.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Nov 9, 2017
@bedevere-bot
Copy link

GH-4356 is a backport of this pull request to the 3.6 branch.

vstinner pushed a commit that referenced this pull request Nov 10, 2017
@pganssle pganssle deleted the datetime_type branch October 25, 2018 14:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants