[issue7879] Too narrow platform check in test_datetime

Changes by R. David Murray : -- Removed message: http://bugs.python.org/msg140810 ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue7879] Too narrow platform check in test_datetime

R. David Murray added the comment: Please implement name+argtuple first and build auto-naming on top of that. Nick's approach would not allow me to specify a custom (hand coded) name for each set of arguments, which is my normal use case. I also would not like the arguments auto-generated i

[issue7879] Too narrow platform check in test_datetime

Alexander Belopolsky added the comment: - 26backport committed in r81618. - merged to release31-maint in r81619. The skipIf patch blocked from release26-maint (skipIf is new in 2.7) and merged into release31-maint in r81620. -- stage: commit review -> committed/rejected status: open -

[issue7879] Too narrow platform check in test_datetime

Alexander Belopolsky added the comment: SkipIf patch committed in r81559 (trunk) and r81560 (py3k). -- ___ Python tracker ___ ___ Pyth

[issue7879] Too narrow platform check in test_datetime

Changes by Alexander Belopolsky : -- versions: +Python 2.6, Python 3.1, Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue7879] Too narrow platform check in test_datetime

Alexander Belopolsky added the comment: >From IRC: Taggnostr: imho tests and doc updates can be backported -- keywords: +26backport ___ Python tracker ___ __

[issue7879] Too narrow platform check in test_datetime

Mark Dickinson added the comment: The skipIf patch looks good to me (though I haven't tested it). -- ___ Python tracker ___ ___ Python

[issue7879] Too narrow platform check in test_datetime

Alexander Belopolsky added the comment: Committed in r81555 (trunk) and r81556 (py3k). Is this a 2.6 backport candidate? I don't think so. Leaving this open to consider using newer unittest.skipIf mechanism. See attached patch, issue7879.diff. -- Added file: http://bugs.python.org

[issue7879] Too narrow platform check in test_datetime

Alexander Belopolsky added the comment: OK, I'll commit it then. -- resolution: -> accepted ___ Python tracker ___ ___ Python-bugs-li

[issue7879] Too narrow platform check in test_datetime

Brian Curtin added the comment: sys.platform will be "win32" for both 32 and 64-bit Windows. As for Cygwin, os.name is "posix" there, and sys.platform is "cygwin", so it should be unaffected. The patch looks fine to me, and we do typically use sys.platform more often than the os.name check.

[issue7879] Too narrow platform check in test_datetime

Alexander Belopolsky added the comment: Mark, I have zero experience with Windows and don't even have a win32 machine to test the patch. On the other hand the patch is so simple that I think it can be reviewed based on theoretical considerations. This is probably bikesheding, but I have a s

[issue7879] Too narrow platform check in test_datetime

Changes by Alexander Belopolsky : -- assignee: -> belopolsky stage: -> commit review ___ Python tracker ___ ___ Python-bugs-list mail

[issue7879] Too narrow platform check in test_datetime

Mark Dickinson added the comment: This looks fine to me. Alexander? -- nosy: +belopolsky, mark.dickinson ___ Python tracker ___ ___ P

[issue7879] Too narrow platform check in test_datetime

Changes by Andrej Krpic : -- components: +Windows type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue7879] Too narrow platform check in test_datetime

New submission from Andrej Krpic : Windows doesn't accept negative timestamps (stated in the comment), yet checks is made against os.name instead of sys.platform. patch fixes that, and also enables windows ce to pass on this test. I think this is better than having os.name in ("nt", "ce"). --