[issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros
Yury V. Zaytsev added the comment: Well, the machine that I had the problem on does no longer exist and I'm not sure whether this is a generic POWER issue. The problem was that I had to cross-compile Python on one generation of POWER machines for another POWER chip using its own special toolchain. I can't tell whether Python build system was doing something wrong, or else whether it was a problem with the toolchain. In theory, both are valid options. Also, I can't test whether the current version of Python has this problem or not with this particular chip / toolchain anymore. Maybe someone who has interest in POWER could try to cross-compile from AMD64 to POWER and check whether the result is still subtly broken... this should be much easier, and if there is a genuine problem with Python build system, it will probably expose it just as well. -- ___ Python tracker <https://bugs.python.org/issue20342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10496] Python startup should not require passwd entry
Yury V. Zaytsev added the comment: Another scenario how this could happen is when Python interpreter is run from a scheduled job on a BlueGene/Q node by the CNK; this is a minimalist execution environment where getpwuid() is unable to resolve home directories for UIDs running the jobs. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20342] Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6
New submission from Yury V. Zaytsev:
Hi,
I've managed to get the test suite of Python to run on Python 3.4.0b2 version
cross-compiled for a specialized POWER chip. I get a number of failures that
seem to have the same nature. I'm under impression, that actually the tests
might need to be adjusted, but I'm not sure about it. I'm happy to provide any
additional information to diagnose this issue. Please let me know if I've
grouped them wrong and have to file a different issue for some tests. Thanks!
== CPython 3.4.0b2 (default, Jan 7 2014, 10:01:53) [GCC 4.4.6]
==
Linux-2.6.32-358.11.1.bgq.el6.bgas_20131217.ppc64-ppc64-with-redhat-6.4-Santiago
big-endian
== hash algorithm: fnv 64bit
== /tmp/test_python_11312
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0,
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
==
FAIL: fromhex (builtins.float)
Doctest: builtins.float.fromhex
--
Traceback (most recent call last):
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/doctest.py, line 2187,
in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for builtins.float.fromhex
File builtins, line unknown line number, in fromhex
--
File builtins, line ?, in builtins.float.fromhex
Failed example:
float.fromhex('-0x1p-1074')
Expected:
-5e-324
Got:
-4.9406564584124654e-324
--
==
FAIL: test_float__format__ (test.test_types.TypesTests)
--
Traceback (most recent call last):
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_types.py, line
467, in test_float__format__
test(1e200, '+', '+1e+200')
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_types.py, line
403, in test
self.assertEqual(f.__format__(format_spec), result)
AssertionError: '+9.9997e+199' != '+1e+200'
- +9.9997e+199
+ +1e+200
--
==
FAIL: SequenceMatcher (difflib)
Doctest: difflib.SequenceMatcher
--
Traceback (most recent call last):
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/doctest.py, line 2187,
in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for difflib.SequenceMatcher
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/difflib.py, line 47, in
SequenceMatcher
--
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/difflib.py, line 83, in
difflib.SequenceMatcher
Failed example:
print(round(s.ratio(), 3))
Expected:
0.866
Got:
0.86599
--
==
FAIL: test_format_testfile (test.test_float.FormatTestCase)
--
Traceback (most recent call last):
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_float.py, line
592, in test_format_testfile
self.assertEqual(fmt % float(arg), rhs)
AssertionError: '0.02' != '0.03'
- 0.02
+ 0.03
--
==
FAIL: test_non_ascii (test.test_format.FormatTest)
--
Traceback (most recent call last):
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_format.py,
line 272, in test_non_ascii
self.assertEqual(format(12.3, \u20076), 12.3\u2007\u2007)
AssertionError: '12.301' != '12.3\u2007\u2007'
- 12.301
+ 12.3\u2007\u2007
--
==
FAIL: test_float_default (test.test_optparse.TestExpandDefaults)
--
Traceback (most recent call last):
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_optparse.py,
line 619, in test_float_default
self.assertHelp(self.parser, expected_help)
File /XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_optparse.py,
line 189, in assertHelp
actual_help + '\n
[issue20342] Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6
Yury V. Zaytsev added the comment: The CPU model is IBM PowerPC A2, the information about the cross-compiler is as follows: $ /bgsys/drivers/ppcfloor/gnu-linux/bin/powerpc64-bgq-linux-gcc -v Reading specs from /bgsys/drivers/toolchain/V1R2M1_base/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.6/specs Target: powerpc64-bgq-linux Configured with: /bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/gcc-4.4.6/configure --prefix=/bgsys/drivers/toolchain/V1R2M1_base/gnu-linux --target=powerpc64-bgq-linux --with-pkgversion=BGQ-V1R2M1-130820 --host=powerpc64-linux-gnu --build=powerpc64-linux-gnu --disable-multilib --enable-shared --enable-secureplt --disable-libmudflap --disable-libspp --with-headers=/bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/build-powerpc64-bgq-linux/tempglibc-4.4.6-install/include --with-libs=/bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/build-powerpc64-bgq-linux/tempglibc-4.4.6-install/lib --with-bin=/bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/build-powerpc64-bgq-linux/tempglibc-4.4.6-install/bin --with-sbin=/bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/build-powerpc64-bgq-linux/tempglibc-4.4.6-install/sbin --with-long-double-128 --enable-threads=posix --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.6 (BGQ-V1R2M1-130820) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20342 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20342] Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6
Changes by Yury V. Zaytsev y...@shurup.com: Added file: http://bugs.python.org/file33613/pyconfig.h ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20342 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros
Yury V. Zaytsev added the comment: I've re-named the issue to reflect the problem. One possible solution that I can see is to use AC_C_BIGENDIAN macro, either exclusively, or only when cross-compiling. In the latest autoconf sources, this macro seems to try to detect the endianness from various macros, and then by grepping the produced object files, so it's safe to use during cross-compilation. Additionally, it allows to set the endianness by hand, if it can't be detected automatically. Any thoughts? -- nosy: +doko title: Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 - Endianness not detected correctly due to AC_RUN_IFELSE macros ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20342 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
New submission from Yury V. Zaytsev: Hi, When I try the following: ./python -m test -v test_hash on a self-compiled Python 3.4.0b2 on RHEL 6.5 / ppc64, it fails. Please let me know which additional information I can supply to diagnose the problem. The complete traceback below: == CPython 3.4.0b2 (default, Jan 6 2014, 15:23:43) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] == Linux-2.6.32-431.el6.ppc64-ppc64-with-redhat-6.5-Santiago big-endian == hash algorithm: siphash24 64bit == /XXX/build/test_python_13082 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_hash test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... ok test_randomized_hash (test.test_hash.DatetimeTimeTests) ... ok test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok test_hash_distribution (test.test_hash.HashDistributionTestCase) ... FAIL test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... ok test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok test_hashable (test.test_hash.HashInheritanceTestCase) ... ok test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok test_ucs2_string (test.test_hash.StrHashRandomizationTests) ... ok == FAIL: test_hash_distribution (test.test_hash.HashDistributionTestCase) -- Traceback (most recent call last): File /XXX/Lib/test/test_hash.py, line 340, in test_hash_distribution self.assertGreater(len(s15), 8, prefix) AssertionError: 1 not greater than 8 : abc -- Ran 30 tests in 0.694s FAILED (failures=1) 1 test failed: test_hash Thanks! -- components: Tests messages: 207533 nosy: zaytsev priority: normal severity: normal status: open title: Test test_hash_distribution fails on RHEL 6.5 / ppc64 type: crash versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: As requested by Victor Stinner: ./python -c 'import sys; print(sys.hash_info)' sys.hash_info(width=64, modulus=2305843009213693951, inf=314159, nan=0, imag=103, algorithm='siphash24', hash_bits=64, seed_bits=128, cutoff=0) -- components: -Interpreter Core type: behavior - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: Sorry for accidentally rolling back your changes to the bug, Antoine! -- components: +Interpreter Core -Tests type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Changes by Yury V. Zaytsev y...@shurup.com: -- components: +Tests ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: == FAIL: test_hash_distribution (test.test_hash.HashDistributionTestCase) (prefix='abc') -- Traceback (most recent call last): File /XXX/Lib/test/test_hash.py, line 341, in test_hash_distribution self.assertGreater(len(s15), 8, prefix) AssertionError: 1 not greater than 8 : abc == FAIL: test_hash_distribution (test.test_hash.HashDistributionTestCase) (prefix='abcdefghabc') -- Traceback (most recent call last): File /XXX/Lib/test/test_hash.py, line 341, in test_hash_distribution self.assertGreater(len(s15), 8, prefix) AssertionError: 1 not greater than 8 : abcdefghabc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: To check whether the problem is in the _le64toh() macro as suggested by Victor Stinner, I've tried the attached patch and the problem is gone. As it turns out, there actually seem to be two problems: First, HAVE_ENDIAN_H is properly defined, because the correct include file is found, but HAVE_LETOH64 is not defined, even though it exists in the system and is working. Therefore, the macro implementation is used instead. However, the second problem is that apparently something is wrong about the macro, even though Victor says it looks fine on the paper, because when macro is replaced by a function from glibc like in my patch, it works. The solution to the first problem, I guess, is to add a proper check to the configure script. I don't have a solution for the second problem. For the record, the test output with the patch applied: bash-4.1$ ./python -m test -v test_hash == CPython 3.4.0b2 (default, Jan 7 2014, 15:03:44) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] == Linux-2.6.32-431.el6.ppc64-ppc64-with-redhat-6.5-Santiago big-endian == hash algorithm: siphash24 64bit == /XXX/build/test_python_27880 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_hash test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... ok test_randomized_hash (test.test_hash.DatetimeTimeTests) ... ok test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok test_hash_distribution (test.test_hash.HashDistributionTestCase) ... ok test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... ok test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok test_hashable (test.test_hash.HashInheritanceTestCase) ... ok test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok test_ucs2_string (test.test_hash.StrHashRandomizationTests) ... ok -- Ran 30 tests in 0.759s OK 1 test OK. -- keywords: +patch Added file: http://bugs.python.org/file33342/pyhash.c.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: I was also asked to mention this: https://github.com/majek/csiphash/blob/master/csiphash.c as an alternative implementation of siphash and platform checks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: After lots of fiddling, I can tell you what's wrong with the macro: apparently it's a compiler bug, visible at -O2 and disappearing at -O1. Assembly output is attached, unfortunately, I'm no ppc64 expert, so I can't immediately tell what exactly went wrong. In any case, the first half of the bug (missing check for HAVE_LETOH64) which triggered the second half still seems valid. I think it's not feasible to upgrade the compiler on RHEL 6.5 (unless someone with a subscription wants to have a go), but fixing the first part should avoid the compiler bug altogether. -- Added file: http://bugs.python.org/file33345/le64toh.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20164] Undocumented KeyError from os.path.expanduser
Yury V. Zaytsev added the comment:
Amusingly, it's also the case on BG/Q compute nodes. Only this morning, I
cooked up the following patch:
--- a/Lib/posixpath.py
+++ b/Lib/posixpath.py
@@ -237,7 +237,11 @@ def expanduser(path):
if i == 1:
if 'HOME' not in os.environ:
import pwd
-userhome = pwd.getpwuid(os.getuid()).pw_dir
+try:
+userhome = pwd.getpwuid(os.getuid()).pw_dir
+except KeyError:
+import warnings
+warnings.warn('Unable to auto-detect $HOME, export it or
functionality such as user-installed modules will not work!', RuntimeWarning)
else:
userhome = os.environ['HOME']
else:
I think it's a bit harsh to fail completely, but returning silently also
doesn't sound like a good idea, so I decided to issue a warning instead; the
wording should be probably tweaked by a native speaker of English though.
What do you think?
--
nosy: +zaytsev
type: - behavior
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20164
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: Hi David, It's gcc from RHEL 6.5 gcc-4.4.7-4.el6.ppc64, the flags are -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes vs. -DNDEBUG -g -fwrapv -O1 -Wall -Wstrict-prototypes. The problem is, I can't isolate it. We honestly tried it with Victor, but gcc doesn't want to miscompile a trivial example. You can see in the attachment as far as I could get: I wrapped the macro in a function, so that it doesn't inline and compared the assembly of the good and bad object files. Hope that helps! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: Look for _le64toh ;-) -- Added file: http://bugs.python.org/file33347/pyhash.preproc.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: Digging more into it, I guess I know why we couldn't come up with a minimal reproducer for this problem. If I compile with -O2 instead of -O1, I get the following warning from gcc: Python/pyhash.c:413: warning: dereferencing pointer 'pt.32' does break strict-aliasing rules which points to the following line: case 4: *((PY_UINT32_T*)pt[0]) = *((PY_UINT32_T*)m[0]); break; If I re-compile with -O2, but -fno-strict-aliasing, then the result doesn't fail. Not sure if siphash code can be changed to not require aliasing, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10496] Python startup should not require passwd entry
Changes by Yury V. Zaytsev y...@shurup.com: -- nosy: +zaytsev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: Related issue where memcpy() was discussed: http://bugs.python.org/issue19183 . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64
Yury V. Zaytsev added the comment: Hi Christian, Dave says it's not a compiler bug; the code is slightly violating the C standard, and the compiler optimizes based on a strict reading of the rules. If I compile with -O2 and higher (while -O3 is the default for Python, as far as I can understand), the compiler correctly warns me about possible issues; as you can see, the macro itself is not at fault, even. It's just that in my particular (rare) mix of circumstances: being big endian, using the macro instead of the glibc function due to the first part of the bug, etc. it results in miscompilation, and in your case, it remains a warning, but the result still works. I think the clean solutions to this problem are as follows: 1) Do not break strict aliasing (use memcpy() instead or something) 2) Disable strict aliasing based optimizations (-fno-strict-aliasing) In addition, fixing the first part of the bug (wrongly using a macro even if le64toh is available), will mask the second part for me again, but I'm not sure if it will re-surface at some point later or not :) Hope that helps! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19517] sysconfig variables introduced by PEP-3149 are currently undocumented
New submission from Yury V. Zaytsev:
PEP-3149 (issue9193) introduces new variables (SO and SOABI) so that one can
find out what are the supported extension suffixes.
Quote from the PEP:
sysconfig.get_config_var('SO')
'.cpython-32mu.so'
sysconfig.get_config_var('SOABI')
'cpython-32mu'
Later, in issue16754, doko introduced EXT_SUFFIX SHLIB_SUFFIX and planned to
update the PEP, but this didn't happen. This caused discrepancy in the news
(issue11234), and the news item was fixed:
http://docs.python.org/3.4/whatsnew/3.2.html?highlight=soabi
sysconfig.get_config_var('SOABI') # find the version tag
'cpython-32mu'
sysconfig.get_config_var('EXT_SUFFIX') # find the full filename extension
'.cpython-32mu.so'
However, the PEP is still not up-to-date and is in conflict with the
implementation.
In an IRC discussion with Barry he suggested that PEPs shouldn't be considered
documentation, so updating the PEP is not the right way to go.
My proposal is then to document the intent behind SO, SOABI, EXT_SUFFIX
SHLIB_SUFFIX on the sysconfig documentation page and mention that they are
platform-specific, and maybe add a link to this page to the PEP.
As of now, I find the situation highly confusing... Any opinions or suggestions
please?
Thanks,
Z.
--
assignee: docs@python
components: Documentation
messages: 202321
nosy: barry, docs@python, doko, zaytsev
priority: normal
severity: normal
status: open
title: sysconfig variables introduced by PEP-3149 are currently undocumented
type: enhancement
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19517
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Yury V. Zaytsev added the comment: Hi Raymond, This is a brilliant idea, but before it hits the streets, couldn't you possibly consider extending it with a kwarg to control the depth of the exception stack? The use case I have for that are snippets like this: with ignored(ValueError, TypeError), ignored(ValueError, TypeError), ignored(ValueError, TypeError): a() b() c() Or else I could write this as with ignored(ValueError, TypeError): a() with ignored(ValueError, TypeError): b() with ignored(ValueError, TypeError): c() ... but either way it looks bad. This looks a bit better to me: with ignored(ValueError, TypeError, depth=3): a() b() c() If you deem this to be unacceptably unpythonic, then please ignore my suggestion. -- nosy: +zaytsev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15806] Add context manager for the try: ... except: pass pattern
Yury V. Zaytsev added the comment: Actually, please disregard my idea. It's way to dangerous, especially in the case of multiple exceptions to ignore :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented
Yury V. Zaytsev added the comment: Hi, I agree with Alexander, I've been recently investigating a related problem and I found the lack of documentation on the subject quite frustrating; I therefore propose the attached patch to the docs. Hope that helps, --Yury. -- keywords: +patch nosy: +zaytsev Added file: http://bugs.python.org/file30952/tpflags-doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5476] datetime: timedelta(minutes = i) silently fails with numpy.int32 input
Yury V. Zaytsev added the comment: NumPy no longer uses the Trac for issues, the tracking has been moved to GitHub. I hope that the problem will be finally solved in NumPy by https://github.com/numpy/numpy/pull/3526 . -- nosy: +zaytsev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2263] struct.pack() + numpy int raises SystemError
Yury V. Zaytsev added the comment: As noted in issue5476, I've submitted a pull request for NumPy: ttps://github.com/numpy/numpy/pull/3526 . I hope that this fixes this problem too: on Py2, I've added Py_TPFLAGS_INT_SUBCLASS, on Py3, NumPy doesn't inherit from int anymore, because it's not a fixed-width integer type. I guess it makes sense to close this bug now. -- nosy: +zaytsev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2263 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18126] Update links to NumPy resources in documentation
New submission from Yury V. Zaytsev: Hi, The links to NumPy sites and documentation are outdated. I replaced them with www.numpy.org, and also the canonical location for documentation (docs.scipy.org). I removed the explicit mention of the PDF file, because the documentation has been split in several guides, so I think it no longer makes sense, and it's better to link docs.scipy.org instead. Thanks! -- assignee: docs@python components: Documentation files: doc-numpy.patch keywords: patch messages: 190543 nosy: docs@python, eric.araujo, ezio.melotti, georg.brandl, zaytsev priority: normal severity: normal status: open title: Update links to NumPy resources in documentation type: enhancement Added file: http://bugs.python.org/file30455/doc-numpy.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
