[issue17756] test_syntax_error fails when run in the installed location
Martin Pitt added the comment:
I can reproduce this here. In that test, I added the following:
with open('/tmp/debug', 'w') as f:
for call in self.stderr.method_calls:
f.write('call: %s\n' % str(call))
This gives:
=== 8<
call: call.write('Python on \nType "help", "copyright", "credits" or "license" for
more information.\n(InteractiveConsole)\n')
call: call.write('Traceback (most recent call last):\n')
call: call.write(' File "/usr/lib/python3.4/code.py", line 90, in runcode\n')
call: call.write('')
call: call.write('exec(code, self.locals)')
call: call.write('\n')
call: call.write(' File "", line 1, in \n')
call: call.write('NameError')
call: call.write(': ')
call: call.write("name 'undefined' is not defined")
call: call.write('\n')
call: call.write('\n')
=== 8<
Observe that the test checks
if 'NameError:' in ''.join(call[1]):
but the "NameError" and the ":" are in two different call lines. I don't know
how self.stderr.method_calls is built, but this sounds like a race
condition/timing or a stdin/out buffering issue? I. e. the original print that
produces the "NameError:" certainly does that in two steps; perhaps the
testsuite thing that repeatedly read()s on stderr catches these two as separate
write()s then?
--
nosy: +pitti
___
Python tracker
<http://bugs.python.org/issue17756>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19352] unittest loader barfs on symlinks
Martin Pitt added the comment: More precisely, it broke unittest's discovery (not specific to autopilot). For any installed test, you now get: $ python -m unittest discover lazr Traceback (most recent call last): File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/lib/python2.7/unittest/__main__.py", line 12, in main(module=None) File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__ self.parseArgs(argv) File "/usr/lib/python2.7/unittest/main.py", line 113, in parseArgs self._do_discovery(argv[2:]) File "/usr/lib/python2.7/unittest/main.py", line 214, in _do_discovery self.test = loader.discover(start_dir, pattern, top_level_dir) File "/usr/lib/python2.7/unittest/loader.py", line 206, in discover tests = list(self._find_tests(start_dir, pattern)) File "/usr/lib/python2.7/unittest/loader.py", line 287, in _find_tests for test in self._find_tests(full_path, pattern): File "/usr/lib/python2.7/unittest/loader.py", line 287, in _find_tests for test in self._find_tests(full_path, pattern): File "/usr/lib/python2.7/unittest/loader.py", line 267, in _find_tests raise ImportError(msg % (mod_name, module_dir, expected_dir)) ImportError: 'test_error' module incorrectly imported from '/usr/lib/python2.7/dist-packages/lazr/restfulclient/tests'. Expected '/usr/lib/python2.7/dist-packages/lazr/restfulclient/tests'. Is this module globally installed? I reverted this patch in Ubuntu for now as a quickfix. This might be specific how Debian installs Python 2 modules. Packages ship them in /usr/share/pyshared//, and for every supported 2.X version, ship /usr/lib/python2.X/dist-packages// which contains only the directories and *.pyc files, but symlinks the *.py files to /usr/share/pyshared//../*.py So, it might be that upstream does not support this symlink layout, but it's the best thing to avoid having to install multiple *.py copies (this is all solved in a much more elegant way with Python 3, of course). But it would be nice if unittest's discovery could still cope with this. Thanks! -- nosy: +pitti ___ Python tracker <http://bugs.python.org/issue19352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19352] unittest loader barfs on symlinks
Martin Pitt added the comment: In this new code: mod_file = os.path.abspath(getattr(module, '__file__', full_path)) realpath = os.path.splitext(os.path.realpath(mod_file))[0] fullpath_noext = os.path.splitext(os.path.realpath(full_path))[0] we get modfile == /usr/lib/python2.7/dist-packages/lazr/restfulclient/tests/test_error.pyc realpath == /usr/lib/python2.7/dist-packages/lazr/restfulclient/tests/test_error fullpath_noext == /usr/share/pyshared/lazr/restfulclient/tests/test_error for this file: lrwxrwxrwx 1 root root 71 Mai 26 2013 /usr/lib/python2.7/dist-packages/lazr/restfulclient/tests/test_error.py -> ../../../../../../share/pyshared/lazr/restfulclient/tests/test_error.py Which is as expected in Debian/Ubuntu as the *.pyc file is a real file in /usr/lib/python2.7, but the *.py is symlinked to /usr/share/. This new patch essentially enforces that the *.py file is not a symlink, which breaks the Debian-ish way of installing python 2 modules. -- ___ Python tracker <http://bugs.python.org/issue19352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19352] unittest loader barfs on symlinks
Martin Pitt added the comment: Yes, this affects python 2.7 only; as I said, this is all solved in python3 by introducing the explicit extensions like __pycache__/*..cpython-33.pyc so that multiple versions can share one directory. With that these symlink hacks aren't necessary any more. -- ___ Python tracker <http://bugs.python.org/issue19352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22526] file iteration SystemError for huge lines (2GiB+)
Martin Pitt added the comment: > How much memory does that whatever is running that test have? Our default is 1 GB for our test runner VMs. I now raised it to 4 GB for python2.7, but we can only do that for our x86 VMs. For other architectures (ppc64el and ARM) the test VMs just don't have that much memory. So indeed it would be nice to skip this test if the machine has less than 4 GB of RAM. Thanks! -- nosy: +pitti ___ Python tracker <http://bugs.python.org/issue22526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22526] file iteration SystemError for huge lines (2GiB+)
Martin Pitt added the comment: > I now raised it to 4 GB for python2.7 This is *still* not enough; I got a success with 6 GB. But this is really demanding.. -- ___ Python tracker <http://bugs.python.org/issue22526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom()
Martin Pitt added the comment: > you could give some kind of command-line flag That already exists -- set PYTHONHASHSEED=0. > But I'll let someone else have the joys of negotiating with Lennart, and I > won't blame the Python devs if using GRND_NONBLOCK unconditionally is less > painful than having to work with the systemd folks. In case it's of any relief: This has nothing to do with having to change anything in systemd itself -- none of the services that systemd ships use Python. The practical case where this bug appeared was cloud-init (which is written in Python), and that wants to run early in the boot sequence even before the network is up (so that tools like "pollinate" which gather entropy from the cloud host don't kick in yet). So if there's any change needed at all, it would be in cloud-init and similar services which run Python during early boot. -- nosy: +pitti title: Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() -> Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom() ___ Python tracker <http://bugs.python.org/issue26839> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
