[issue6608] asctime causing python to crash
James Abbatiello abb...@gmail.com added the comment: Further investigation shows that MS asctime() doesn't like leap seconds and causes an assertion when passing (2008, 12, 31, 23, 59, 60, 2, 366, -1) - 'Wed Dec 31 23:59:60 2008'. Given that and since asctime() is such a simple function I think it makes more sense to roll our own. Attached is a rough patch which does this. It pulls the bounds checking used in strftime() out into its own function so it can be used in both places. Overriding ctime() is necessary because Windows decided to use %02d instead of %3d to print the day of the month. Without overriding ctime() the output of ctime(t) would be different from asctime(localtime(t)) and cause test_conversion() to fail. There is a USE_SYSTEM_ASCTIME switch to decide whether to use the system asctime() or the internal one. -- keywords: +patch Added file: http://bugs.python.org/file14628/asctime.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5093] 2to3 with a pipe on non-ASCII script
James Abbatiello abb...@gmail.com added the comment: In what case(s) do you propose the output to be encoded in UTF-8? If output is to a terminal and that terminal is set to Latin-1 or cp437 or whatever then outputting UTF-8 in that case will only show garbage characters to the user. If output is to a file then using the encoding of the input file makes the most sense to me. Assume you have a simple program encoded in Latin-1 that prints out a string with some non-ASCII characters. The patch is printed in UTF-8 encoding and redirected to a file. The patch program has no idea what encodings are used and it will just compare the bytes in the original to the bytes in the patch file. These won't match since the encodings are different and he patch will fail. If the output is to a pipe then I'm not sure what the right thing is. It may be intended for display on the screen with something like `less` or it may not. I don't think there's a good solution for this. So following the above logic the patch attached here does the following: 1) If output is to a terminal (sys.stdout.encoding is set) then use that encoding for output 2) Otherwise if an encoding was determined for the input file, use that encoding for output 3) If all else fails, use 'ascii' encoding. If the input contained non-ASCII characters and no encoding has been determined for the input then this will cause an exception to be raised. I think this can only happen when reading the input file from stdin. Perhaps that case needs to be looked at for how to detect the encoding of stdin. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5093 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6608] asctime causing python to crash
James Abbatiello abb...@gmail.com added the comment: Since there's no good way to disable the assertion (see issue4804), checking the validity of the argument beforehand looks like an option. The checking that's currently being done in the strftime() implementation looks useful but it is not enough. The checking in the MS implementation of asctime() is very strict and validates the entire date, not just one field at a time. So there's no way to print out non-existant dates like (2009, 2, 31, 0, 0, 0, 0, 0, 0) - 'Mon Feb 31 00:00:00 2009'. I don't know if anybody is relying on that kind of behavior. If not then the function could be limited to accept only valid dates. Alternatively we could just not call down to asctime() but instead provide our own implementation using sprintf/strftime. -- nosy: +abbeyj ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6599] 2to3 test_print_function_option fails on Windows
New submission from James Abbatiello abb...@gmail.com: test_print_function_option is failing on Windows. Patch attached. Output of failure: C:python test.py test_all_project_files (lib2to3.tests.test_all_fixers.Test_all) ... snip\2to3\lib2to3\refactor.py:194: DeprecationWarning: the 'print_function' option is deprecated DeprecationWarning) snip == FAIL: test_print_function_option (lib2to3.tests.test_refactor.TestRefactoringTool) -- Traceback (most recent call last): File snip\2to3\lib2to3\tests\test_refactor.py, line 51, in test_print_function_option self.assertEqual(len(w), 1) AssertionError: 0 != 1 -- On my system test_all_fixers.py comes before test_refactor.py in the output of os.listdir(). The warning gets fired by test_all_fixers and then won't be retriggered in test_refactor. Since the option doesn't do anything anymore I've just removed its use. -- components: 2to3 (2.x to 3.0 conversion tool) files: print_function_option.patch keywords: patch messages: 91075 nosy: abbeyj, benjamin.peterson severity: normal status: open title: 2to3 test_print_function_option fails on Windows Added file: http://bugs.python.org/file14603/print_function_option.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5093] 2to3 with a pipe on non-ASCII script
James Abbatiello abb...@gmail.com added the comment: The --no-diffs option was recently added which looks like a good workaround. Here's an attempt at a solution. If sys.stdout has an encoding set then use that, just as is being done now. If there is no encoding (implying ascii) then use the encoding of the input file. -- nosy: +abbeyj Added file: http://bugs.python.org/file14604/output_encoding.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5093 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6358] os.popen exit code inconsistent
New submission from James Abbatiello abb...@gmail.com: Start a process with os.popen() and then try to get its exit code by closing the resulting file handle. The value returned is inconsistent between 2.x and 3.x. Example: Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os f = os.popen(exit 42, r) f.close() 42 Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os f = os.popen(exit 42, r) f.close() 10752 divmod(10752, 256) (42, 0) The docs for 2.6.2 say that the return value is the exit status of the process as returned by wait() (http://docs.python.org/library/os.html#os.popen). That's what 3.1 is doing(*) but not what 2.6 has actually been doing. In 2.6 the exit code (not exit status) is returned; if the process didn't exit cleanly then an exception is thrown. The docs for 3.1 say that os.popen() is documented in the section File Object Creation but it is not. http://docs.python.org/3.1/library/os.html#process-management http://docs.python.org/3.1/library/os.html#file-object-creation It doesn't seem to be documented at all in 3.1 although it is mentioned many times on that page. Since os.popen() is mostly for backward compatibility, should the 3.x behavior be changed to match the actual 2.6 behavior? (*) It looks like 3.1 doesn't return the right value if the subprocess is killed by a signal but I can't test this on win32. -- assignee: georg.brandl components: Documentation, Library (Lib) messages: 89792 nosy: abbeyj, georg.brandl severity: normal status: open title: os.popen exit code inconsistent versions: Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6358 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6250] Python compiles dead code
James Abbatiello abb...@gmail.com added the comment: Raymond, I've updated peephole.c to allow code to terminate with any of RETURN_VALUE, END_FINALLY or RAISE_VARARGS [0-3]. I also added tests to test_peepholer.py to make sure the peepholer still works in these cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6250] Python compiles dead code
New submission from James Abbatiello abb...@gmail.com: Python currently emits bytecode for code that is unreachable (e.g. following a return statement). This doesn't hurt anything but it takes up space doing nothing. This patch attempts to avoid generating any bytecode in this situation. There's an optional warning, enabled with the -r command line switch, which notifies you if any unreachable code is found. Running regrtest.py with this switch produces a bit of noise but also revealed issue6227 which looks like a real bug. -- components: Interpreter Core files: deadcode.patch keywords: patch messages: 89183 nosy: abbeyj, collinwinter, jyasskin, pitrou severity: normal status: open title: Python compiles dead code versions: Python 2.7 Added file: http://bugs.python.org/file14252/deadcode.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6227] doctest_aliases doesn't test duplicate removal
New submission from James Abbatiello abb...@gmail.com: The file Lib/test/doctest_aliases.py is used by test_doctest to check the handling of duplicate removal. The g = f line in this file is one indent too far to the right so instead of creating an alias for f called g it is just unreachable code inside of f. Since there is no alias there is no need to remove duplicates and the test passes trivially. I think this affects all versions but I've only checked on 2.7. -- components: Tests files: doctest_aliases.patch keywords: patch messages: 89027 nosy: abbeyj severity: normal status: open title: doctest_aliases doesn't test duplicate removal versions: Python 2.7 Added file: http://bugs.python.org/file14210/doctest_aliases.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6227 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6199] test_unittest fails on Windows
New submission from James Abbatiello abb...@gmail.com: test_unittest fails on Windows with: == FAIL: test_find_tests_with_package (test.test_unittest.TestDiscovery) -- Traceback (most recent call last): File C:\Projects\python-trunk\lib\test\test_unittest.py, line 3540, in test_find_tests_with_package self.assertEqual(suite, ['load_tests', '/foo/test_directory2 module tests']) AssertionError: Lists differ: ['load_tests', '/foo\\test_dir... != ['load_tests', '/foo/test_dire... First differing element 1: /foo\test_directory2 module tests /foo/test_directory2 module tests - ['load_tests', '/foo\\test_directory2 module tests'] ? ^^ + ['load_tests', '/foo/test_directory2 module tests'] ? ^ -- Patch attached. -- components: Tests, Windows files: test_unittest_on_windows.patch keywords: patch messages: 88923 nosy: abbeyj severity: normal status: open title: test_unittest fails on Windows versions: Python 2.7 Added file: http://bugs.python.org/file14191/test_unittest_on_windows.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6201] test_winreg fails
New submission from James Abbatiello abb...@gmail.com: test_winreg fails with: == ERROR: testLocalMachineRegistryWorks (test.test_winreg.WinregTests) -- Traceback (most recent call last): snip File C:\Projects\python-trunk\lib\test\test_winreg.py, line 86, in ReadTestData with OpenKey(key, sub_key) as sub_key: AttributeError: __exit__ -- _winreg.OpenKey() returns a PyHKEY. This type can no longer be used in a with statement after r72912 introduced the SETUP_WITH opcode. The old way used PyObject_GetAttr() to get __enter__ and __exit__ which works fine with PyHKEY since it has a tp_getattr function. The new way uses _PyObject_LookupSpecial() which uses the MRO and the dict of the object. I guess the right fix here is to update PyHKEY so it uses the modern APIs but I don't know how to do this without breaking the special casing for the handle member. Using T_INT isn't quite correct since it is a pointer not an int. -- components: Tests, Windows messages: 88926 nosy: abbeyj severity: normal status: open title: test_winreg fails versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6197] test__locale fails with RADIXCHAR on Windows
New submission from James Abbatiello abb...@gmail.com: regrtest.py test__locale fails with: test__locale test test__locale crashed -- type 'exceptions.ImportError': cannot import name RADIXCHAR 1 test failed: test__locale The attached patch backports the fix from issue5643 -- components: Tests, Windows files: test__locale_on_windows.patch keywords: patch messages: 88919 nosy: abbeyj, benjamin.peterson, ocean-city severity: normal status: open title: test__locale fails with RADIXCHAR on Windows versions: Python 2.7 Added file: http://bugs.python.org/file14190/test__locale_on_windows.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6197 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6198] test_float fails on Windows
New submission from James Abbatiello abb...@gmail.com: test_float fails on Windows with: == FAIL: test_format_testfile (test.test_float.IEEEFormatTestCase) -- Traceback (most recent call last): File C:\Projects\python-trunk\lib\test\test_float.py, line 319, in test_format_testfile self.assertEqual(fmt % float(arg), rhs) AssertionError: '3' != '2' -- The problematic line from formatfloat_testcases.txt is: %.0f 2.5 - 2 On some systems *printf() uses round-to-even. But the Windows CRT uses round-half-away-from-zero. Consider the following C code: printf(%+.1f - %+.0f\n, -2.5, -2.5); printf(%+.1f - %+.0f\n, -1.5, -1.5); printf(%+.1f - %+.0f\n, +1.5, +1.5); printf(%+.1f - %+.0f\n, +2.5, +2.5); On Linux this will produce: -2.5 - -2 -1.5 - -2 +1.5 - +2 +2.5 - +2 And on Windows: -2.5 - -3 -1.5 - -2 +1.5 - +2 +2.5 - +3 -- components: Tests, Windows messages: 88922 nosy: abbeyj severity: normal status: open title: test_float fails on Windows versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6134] 2to3 tests fail on Windows due to line endings
New submission from James Abbatiello abb...@gmail.com: The tests for 2to3 currently fail on Windows. Data is read from a file in binary mode and then written to a temporary file in text mode which doubles up the carriage returns. Additionally, several files are missing the svn:eol-style property. The attached patch addresses both problems. -- components: 2to3 (2.x to 3.0 conversion tool) files: 2to3_native_eol.patch keywords: patch messages: 88464 nosy: abbeyj severity: normal status: open title: 2to3 tests fail on Windows due to line endings Added file: http://bugs.python.org/file14102/2to3_native_eol.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
