- 26 Nov, 2020 6 commits
-
-
Kirill Smelkov authored
There was an assert because sys.path[0] is setup as realpath (real, not relative), but if exe was given as relative path it was raising like below: gpython/gpython_test.py::test_pymain_run_via_relpath GPython 0.0.7.post1 [gevent 20.9.0] / CPython 3.8.6 Traceback (most recent call last): File "./__init__.py", line 482, in <module> main() File "./__init__.py", line 366, in main pymain(argv, init) File "./__init__.py", line 82, in pymain raise RuntimeError('pymain: internal error: sys.path[0] was not set by underlying python to dirname(exe):' RuntimeError: pymain: internal error: sys.path[0] was not set by underlying python to dirname(exe): exe: ./__init__.py sys.path[0]: /home/kirr/src/tools/go/pygolang-master/gpython FAILED -> Fix it by setting up exe as realpath.
-
Kirill Smelkov authored
This is generic step and should be done under both gpython and standard python. Handling sys.executable inside pymain offloads users from setting up sys.executable by themselves, e.g. as in here: https://lab.nexedi.com/nexedi/slapos/blob/46ed2afe/component/pygolang/buildout.cfg#L39-43
-
Kirill Smelkov authored
In other words pymain now requires to be passed in full argv when called. We will need exe=argv[0] in a followup patch to be able to reexecute underlying python interpreter when given options like -O, -S, etc... This is change in behaviour and in general must come with changing pymain name - e.g. to pymain2 - so that old pymain continues to work as before. However since there are not so many known pymain users, we can probably do this change in place since we'll care ourselves about all those users: - [python-interpreter] in SlapOS: https://lab.nexedi.com/nexedi/slapos/blob/46ed2afe/component/pygolang/buildout.cfg#L30-53 - pyruntraced in Go123: https://lab.nexedi.com/kirr/go123/blob/96046edf/tracing/cmd/pyruntraced - zobjtrace in ZODB: https://lab.nexedi.com/kirr/ZODB/blob/07c21671/zobjtrace So I hope it is ok.
-
Kirill Smelkov authored
Python allows multiple single-letter options and their arguments to be coming on single argument, for example: python -OQc'print 1' python -OQc 'print 1' python -OQ -c 'print 1' etc... We are currently trying to handle that at every option, but even though it kind of works, it is limited and will break once we will start adding options. -> Refactor options parsing into getopt-style helper. We cannot use getopt itself because it will complain e.g. on `gpython file.py --my-custom-opt` that my-custom-opt is unexpected.
-
Jérome Perrin authored
follow up of 64088e8a (gpython: Don't inherit __future__ when executing scripts, 2020-11-26) /reviewed-by @kirr /reviewed-on nexedi/pygolang!9
-
Jérome Perrin authored
Because we use execfile to emulate "python script.py" invocation, future enabled in gpython main script are also enabled in "script.py" and because we use print_function feature, it was also applied in "script.py". On python 2 when "script.py" uses print statements they were considered as SyntaxError. Hopefuly, compile has a `dont_inherit` flag which does exactly what we need here: compile the script without inheriting futures enabled, so we use compile with this flag. /reviewed-by @kirr /reviewed-on nexedi/pygolang!8
-
- 02 Nov, 2020 1 commit
-
-
Kirill Smelkov authored
Nxdtest[1] is tox-like tool to run tests under Nexedi testing infrastructure. [1] https://lab.nexedi.com/nexedi/nxdtest /cc @jerome, @gabriel /reviewed-on nexedi/pygolang!6
-
- 14 Oct, 2020 5 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
With buildout raw underlying python interpreter does not have access to eggs with which gpython script was generated. See previous commit for details.
-
Kirill Smelkov authored
When buildout generates scripts, it injects the following prologue for them: #!/path/to/underlying/python import sys sys.path[0:0] = [ 'path/to/egg1', 'path/to/egg2', ... ] import SCRIPT SCRIPT.main() This way path to eggs are inserted before what was originally sys.path[0] and it breaks gpython check that `sys.path[0] == exedir`. -> Fix it by detecting buildout and in that case verifying that exedir is only present in sys.path, not located in sys.path[0].
-
Kirill Smelkov authored
We were appending whole $PYTHONPATH to pathv - a vector of path. But we should instead first split $PYTHONPATH by pathsep and extend pathv.
-
Kirill Smelkov authored
It is os.pathsep, which is ';' on Windows.
-
- 22 Sep, 2020 6 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
This continues 6b4990f6 (gpython: Fix pymain to properly setup sys.path[0]) - now we add test and verify that gpython actually sets sys.path in the same way as underlying python does: - don't add directory of gpython to sys.path - for `gpython file` add to sys.path[0] realpath(dir(file)) instead of dir(file) (see PySys_SetArgvEx for the reference, and else - if we do not make this change - added test breaks) - for `gpython -m mod` add to sys.path[0] realpath('') instead of ''. This exactly matches PY3 behaviour, while PY2 behaviour is to add '' However PY3 behaviour * is more sane, and * fixes test_defer_excchain_traceback on py27-gevent -> so we stick to it. Now all tests pass again.
-
Kirill Smelkov authored
GPython preimports golang and gevent, but until now, it was preimporting them before adjusting sys.path according to given -c/-m/file/... And this was leading to difference in behaviour with standard Python where e.g. `import golang` might result in different files loaded if e.g. golang/ is there on cwd and -c/-m was given. -> Rework gpython startup so that golang/gevent preimport happens after sys.path initialization. This fixes `tox -e py27-gevent` which was previously failing on test_defer_excchain_dump_pytest / test_defer_excchain_dump_ipython because dumped paths were different than expected ones. It, however, breaks test_defer_excchain_traceback on py27-gevent. -> We'll do more fixups to sys.path handling in the next patch which will fix that failure as well.
-
Kirill Smelkov authored
We'll need this in the next patch, where golang/gevent preimport will be moved from "before call to pymain", to "in between option parsing and interpreter start".
-
Kirill Smelkov authored
There, with pytest 6.0.x, pytest emits its internal deprecation warning (the usage of deprecated attribute is inside pytest): .../_pytest/compat.py:340: PytestDeprecationWarning: The TerminalReporter.writer attribute is deprecated, use TerminalReporter._tw instead at your own risk. See https://docs.pytest.org/en/stable/deprecations.html#terminalreporter-writer for more information. return getattr(object, name, default) Which leads to test_defer_excchain_dump_pytest failure since this test verifies stderr to be empty: def test_defer_excchain_dump_pytest(): tbok = readfile(dir_testprog + "/golang_test_defer_excchain.txt-pytest") retcode, stdout, stderr = _pyrun(["-m", "pytest", "-o", "python_functions=main", "--tb=short", "golang_test_defer_excchain.py"], cwd=dir_testprog, stdout=PIPE, stderr=PIPE) assert retcode != 0, (stdout, stderr) > assert stderr == b"" E AssertionError: assert b'/home/kirr/...e, default)\n' == b'' E Full diff: E - b'' E + ( E + b'/home/kirr/src/tools/go/py3dbg.venv/lib/python3.8/site-packages/_pytest/comp' E + b'at.py:340: PytestDeprecationWarning: The TerminalReporter.writer attribute i' E + b's deprecated, use TerminalReporter._tw instead at your own risk.\nSee htt' E + b'ps://docs.pytest.org/en/stable/deprecations.html#terminalreporter-writer for'... E E ...Full output truncated (3 lines hidden), use '-vv' to show -> Fix it by not letting spawned pytest to emit deprecation warnings in that test.
-
Kirill Smelkov authored
We'll need warnings control in the next patch to fix Pytest integration wrt python3-dbg with `-W ignore::DeprecationWarning`.
-
- 21 Sep, 2020 1 commit
-
-
Kirill Smelkov authored
Reorganize parsiong of command line options so that first all options are parsed in a loop, and only after that a module/file/command is executed. This is needed as preparatory step for next patch: there we'll add support for -W, and `-W arg` can be given multiple times and has to be processed multiple times by creating multiple corresponding warning filters. Because those warning filters has to be applied uniformly to all 4 codepaths of execution phase (-m/-c/file/interactive console), it makes sense to move execution phase to after options parsing and inject common runtime preparatory steps right before that. This logic generally applies not only to -W, but to all other python options - e.g. -Q,-u,...
-
- 18 Sep, 2020 3 commits
-
-
Kirill Smelkov authored
Current Debian testing builds libtsan/libasan with --as-needed, which leads to libstdc++.so not being linked in. Compare Debian 10: kirr@link:~/src/tools/go/pygolang$ ldd /usr/lib/x86_64-linux-gnu/libasan.so.5 linux-vdso.so.1 (0x00007ffe7e97f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f00ad9d5000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f00ad9cb000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f00ad9aa000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f00ad7d2000) <-- libstdc++ libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f00ad64f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f00ad48e000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f00ad472000) /lib64/ld-linux-x86-64.so.2 (0x00007f00ae7c8000) to Debian testing: kirr@deco:~/src/tools/go/pygolang$ ldd /usr/lib/x86_64-linux-gnu/libasan.so.6 linux-vdso.so.1 (0x00007ffe15d0b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f53ba069000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f53ba047000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f53b9f03000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f53b9d3e000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f53b9d24000) /lib64/ld-linux-x86-64.so.2 (0x00007f53baa6b000) where libstdc++ is not being linked to libasan.so This leads to the following crash: golang/golang_test.py::test_pyx_select_inplace ==181237==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_interceptors.cpp:333 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0) #0 0x7f76aa9f4657 (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xb2657) #1 0x7f76aaa11d5a (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xcfd5a) #2 0x7f76aa97ac14 in __cxa_throw (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x38c14) #3 0x7f76a497a9ef in panic golang/runtime/libgolang.cpp:79 #4 0x7f76a497e9a9 in _chanselect golang/runtime/libgolang.cpp:956 #5 0x7f76a455573c in select<1> golang/libgolang.h:535 #6 0x7f76a454fa4b in _test_select_inplace() golang/runtime/libgolang_test.cpp:417 #7 0x7f76a452781e in __pyx_pf_6golang_12_golang_test_30test_select_inplace golang/_golang_test.cpp:4859 #8 0x7f76a45277db in __pyx_pw_6golang_12_golang_test_31test_select_inplace golang/_golang_test.cpp:4821 explained by https://github.com/google/sanitizers/issues/934 -> work it around by manually preloading libstdc++ as well.
-
Kirill Smelkov authored
test_defer_excchain_dump_ipython was setting fresh env anew, thus not propagating $LD_PRELOAD that trun sets when libgolang was built with thread or address sanitizer. This way the subprocess spawned for IPython was failing with e.g. ==152924==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. -> Fix it by only adjusting environment for spawned IPython instead of setting it completely anew. Fixes: 09629367 (golang: tests: Add tests for IPython and Pytest integration patches)
-
Kirill Smelkov authored
For example if test_defer_excchain_dump_ipython fails the output was: > assert retcode == 0 E assert 1 == 0 and it was unclear what was going on. Now the output is e.g. > assert retcode == 0, (stdout, stderr) E AssertionError: ('', '==152924==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. E ') E assert 1 == 0 Amends: 09629367 (golang: tests: Add tests for IPython and Pytest integration patches) and bb9a94c3 (golang: Teach defer to chain exceptions (PEP 3134) even on Python2).
-
- 30 Jul, 2020 4 commits
-
-
Kirill Smelkov authored
Until now gpython was always activating gevent on startup + adding goodness such as "always UTF-8 default encoding"; go, chan, b/u and friends available from builtin namespace, etc... While those goodness are sometimes useful on their own, it is not always appropriate to force a project to switch from threads to gevent. For this reason add a flag to select which runtime - either gevent or threads - gpython should use. gpython -Xgpython.runtime=gevent selects gevent, while gpython -Xgpython.runtime=threads selects threads. Gevent remains the default. It is also possible to specify desired runtime via $GPYTHON_RUNTIME environment variable. /reviewed-on nexedi/pygolang!5
-
Kirill Smelkov authored
Restructure code a bit to prepare it for the next patch. Plain code movement. /reviewed-on nexedi/pygolang!5
-
Kirill Smelkov authored
On CPython: $ python -V Python 2.7.18 $ gpython -V GPython 0.0.6.post2 [gevent 20.6.2] / CPython 2.7.18 On PyPy: $ python -V Python 3.6.9 (2ad108f17bdb, Apr 07 2020, 02:59:05) [PyPy 7.3.1 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] $ gpython -V GPython 0.0.6.post2 [gevent 20.5.0] / PyPy 7.3.1 / Python 3.6.9 /reviewed-on !5
-
Kirill Smelkov authored
And same for -m<module> - becuase Python supports it this way. Before the patch: $ python '-cprint "hello world"' hello world $ gpython '-cprint "hello world"' unknown option: '-cprint "hello world"' After the patch: $ python '-cprint "hello world"' hello world $ gpython '-cprint "hello world"' hello world /reviewed-on !5
-
- 07 Jul, 2020 3 commits
-
-
Kirill Smelkov authored
kirr@deco:~$ python3.8 -v import _frozen_importlib # frozen import _imp # builtin import '_thread' # <class '_frozen_importlib.BuiltinImporter'> import '_warnings' # <class '_frozen_importlib.BuiltinImporter'> import '_weakref' # <class '_frozen_importlib.BuiltinImporter'> import '_frozen_importlib_external' # <class '_frozen_importlib.FrozenImporter'> import '_io' # <class '_frozen_importlib.BuiltinImporter'> import 'marshal' # <class '_frozen_importlib.BuiltinImporter'> import 'posix' # <class '_frozen_importlib.BuiltinImporter'> import _thread # previously loaded ('_thread') import '_thread' # <class '_frozen_importlib.BuiltinImporter'> import _weakref # previously loaded ('_weakref') import '_weakref' # <class '_frozen_importlib.BuiltinImporter'> # installing zipimport hook import 'time' # <class '_frozen_importlib.BuiltinImporter'> <-- NOTE import 'zipimport' # <class '_frozen_importlib.FrozenImporter'> # installed zipimport hook See https://github.com/python/cpython/commit/79d1c2e6c9d1 for details (`import time` in zipimport.py)
-
Kirill Smelkov authored
-
- 29 May, 2020 1 commit
-
-
Kirill Smelkov authored
Gevent is major component gpython builds on - it deserves to be included into version and is handy to know if one hits a bug with gpython - to see in which particular runtime environment the bug was hit. Before: $ gpython Python 3.7.3 (default, Dec 20 2019, 18:57:59) [GCC 8.3.0] [GPython 0.0.6.post2] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> After: $ gpython Python 3.7.3 (default, Dec 20 2019, 18:57:59) [GCC 8.3.0] [GPython 0.0.6.post2] [gevent 20.5.1] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> /cc @gabriel, @jerome /proposed-for-review-on: nexedi/pygolang!4
-
- 21 May, 2020 2 commits
-
-
Kirill Smelkov authored
Add tests for patches to third-party software that were added in nexedi/pygolang@bb9a94c3. /cc @gabriel, @jerome /reviewed-on: nexedi/pygolang!2
-
Kirill Smelkov authored
This makes recovered exception object a good target to be explicitly chained into (PEP 3134) via .__cause__ because without .__traceback__ the information about where/how recovered exception originated would be lost. In turn, having recover to always return full exception info, should allow to use recover in "add error context"-style utilities. /reviewed-on: !3
-
- 20 May, 2020 1 commit
-
-
Kirill Smelkov authored
Starting from setuptools-dso 1.7 pyx.build no longer misses to (re)compile dsos when `build_ext -i` is run: https://github.com/mdavidsaver/setuptools_dso/pull/10 https://github.com/mdavidsaver/setuptools_dso/commit/84e06348 Previously `pip install -e` would just fail when run afresh because DSOs were not built, and so link ext->dso was failing.
-
- 19 May, 2020 4 commits
-
-
Kirill Smelkov authored
bb9a94c3 (golang: Teach defer to chain exceptions (PEP 3134) even on Python2) added integration patches for IPython and Pytest to properly dump tracebacks for chained exceptions even on Python2. However the functionality of patches was tested only manually. -> Add corresponding tests to verify how IPython and Pytest behaves when dumping tracebacks.
-
Kirill Smelkov authored
assertDoc normalizes paths in compared texts with the idea for etalon output to contain PYGOLANG instead of whatever actual path there will be when testing the package. This already works. However IPython, when dumping tracebacks, tries to shorten paths and abbreviate $HOME with ~ in them. This breaks normalization which misses to convert prefix of those paths into PYGOLANG. -> Fix it by teaching assertDoc to also handle paths that start with ~ and correctly normalize them. This will be needed in the next patch where we will add tests for how ipython and pytest dump tracebacks for chained exceptions.
-
Kirill Smelkov authored
We are going to use it from several places.
-
Kirill Smelkov authored
Paths to the directories are already used in several functions, and are going to be used more. Move them to common place to avoid duplication.
-
- 03 May, 2020 2 commits
-
-
Kirill Smelkov authored
Starting from setuptools-dso 1.6 pyx.build no longer fails on macOS due to: https://github.com/mdavidsaver/setuptools_dso/commit/dd2cf303 https://github.com/mdavidsaver/setuptools_dso/commit/6883d6dc https://github.com/mdavidsaver/setuptools_dso/commit/78ae8852 https://github.com/mdavidsaver/setuptools_dso/pull/9 https://github.com/mdavidsaver/setuptools_dso/issues/8 It was previously failing with setuptools-dso==1.5: (py3.venv) kirr@Kirills-iMac pygolang % python -m pytest ==================================== test session starts ===================================== platform darwin -- Python 3.7.6, pytest-5.3.5, py-1.8.1, pluggy-0.13.1 rootdir: /Users/kirr/pygolang collected 100 items golang/_gopath_test.py .. [ 2%] golang/context_test.py .. [ 4%] golang/cxx_test.py .. [ 6%] golang/errors_test.py ........ [ 14%] golang/fmt_test.py ... [ 17%] golang/golang_test.py ............................................. [ 62%] golang/io_test.py . [ 63%] golang/strconv_test.py .. [ 65%] golang/strings_test.py ..... [ 70%] golang/sync_test.py ............. [ 83%] golang/time_test.py ........ [ 91%] golang/pyx/build_test.py FF. [ 94%] golang/pyx/runtime_test.py . [ 95%] gpython/gpython_test.py ssss. [100%] ========================================== FAILURES ========================================== _______________________________________ test_pyx_build _______________________________________ def test_pyx_build(): pyxuser = testprog + "/golang_pyx_user" pyrun(["setup.py", "build_ext", "-i"], cwd=pyxuser) # run built test. _ = pyout(["-c", # XXX `import golang` is a hack: it dynamically loads _golang.so -> libgolang.so, # and this way dynamic linker already has libgolang.so DSO found and in # memory for all further imports. If we don't, current state of setuptools_dso # is that `import pyxuser.test` will fail finding libgolang.so. "import golang;" + > "from pyxuser import test; test.main()"], cwd=pyxuser) golang/pyx/build_test.py:40: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ golang/golang_test.py:1709: in pyout return pyrun(argv, stdin=stdin, stdout=stdout, stderr=stderr, **kw) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ argv = ['-c', 'import golang;from pyxuser import test; test.main()'], stdin = None, stdout = b'', stderr = None kw = {'cwd': '/Users/kirr/pygolang/golang/pyx/testprog/golang_pyx_user'}, retcode = 1 def pyrun(argv, stdin=None, stdout=None, stderr=None, **kw): retcode, stdout, stderr = _pyrun(argv, stdin=stdin, stdout=stdout, stderr=stderr, **kw) if retcode: > raise RuntimeError(' '.join(argv) + '\n' + (stderr and str(stderr) or '(failed)')) E RuntimeError: -c import golang;from pyxuser import test; test.main() E (failed) golang/golang_test.py:1703: RuntimeError ------------------------------------ Captured stdout call ------------------------------------ running build_ext cythoning pyxuser/test.pyx to pyxuser/test.cpp building 'pyxuser.test' extension creating build creating build/temp.macosx-10.15-x86_64-3.7 creating build/temp.macosx-10.15-x86_64-3.7/pyxuser clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers -I/Users/kirr/pygolang -I/Users/kirr/py3.venv/bin/../include/site/python3.7 -I/usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/include/python3.7m -c pyxuser/test.cpp -o build/temp.macosx-10.15-x86_64-3.7/pyxuser/test.o -std=c++11 -fno-strict-aliasing creating build/lib.macosx-10.15-x86_64-3.7 creating build/lib.macosx-10.15-x86_64-3.7/pyxuser clang++ -bundle -undefined dynamic_lookup build/temp.macosx-10.15-x86_64-3.7/pyxuser/test.o -L/Users/kirr/pygolang/golang/runtime -llibgolang -o build/lib.macosx-10.15-x86_64-3.7/pyxuser/test.cpython-37m-darwin.so otool -L build/lib.macosx-10.15-x86_64-3.7/pyxuser/test.cpython-37m-darwin.so build/lib.macosx-10.15-x86_64-3.7/pyxuser/test.cpython-37m-darwin.so: @loader_path/liblibgolang.0.1.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) install_name_tool -change @loader_path/liblibgolang.0.1.dylib @loader_path/../golang/runtime/liblibgolang.0.1.dylib build/lib.macosx-10.15-x86_64-3.7/pyxuser/test.cpython-37m-darwin.so otool -L build/lib.macosx-10.15-x86_64-3.7/pyxuser/test.cpython-37m-darwin.so build/lib.macosx-10.15-x86_64-3.7/pyxuser/test.cpython-37m-darwin.so: @loader_path/../golang/runtime/liblibgolang.0.1.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) copying build/lib.macosx-10.15-x86_64-3.7/pyxuser/test.cpython-37m-darwin.so -> pyxuser ------------------------------------ Captured stderr call ------------------------------------ Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: dlopen(/Users/kirr/pygolang/golang/pyx/testprog/golang_pyx_user/pyxuser/test.cpython-37m-darwin.so, 2): Library not loaded: @loader_path/../golang/runtime/liblibgolang.0.1.dylib Referenced from: /Users/kirr/pygolang/golang/pyx/testprog/golang_pyx_user/pyxuser/test.cpython-37m-darwin.so Reason: image not found _______________________________________ test_dso_build _______________________________________ def test_dso_build(): dsouser = testprog + "/golang_dso_user" pyrun(["setup.py", "build_dso", "-i"], cwd=dsouser) pyrun(["setup.py", "build_ext", "-i"], cwd=dsouser) # run built test. _ = pyout(["-c", # XXX `import golang` is a hack - see test_pyx_build for details. "import golang;" + > "from dsouser import test; test.main()"], cwd=dsouser) golang/pyx/build_test.py:54: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ golang/golang_test.py:1709: in pyout return pyrun(argv, stdin=stdin, stdout=stdout, stderr=stderr, **kw) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ argv = ['-c', 'import golang;from dsouser import test; test.main()'], stdin = None, stdout = b'', stderr = None kw = {'cwd': '/Users/kirr/pygolang/golang/pyx/testprog/golang_dso_user'}, retcode = 1 def pyrun(argv, stdin=None, stdout=None, stderr=None, **kw): retcode, stdout, stderr = _pyrun(argv, stdin=stdin, stdout=stdout, stderr=stderr, **kw) if retcode: > raise RuntimeError(' '.join(argv) + '\n' + (stderr and str(stderr) or '(failed)')) E RuntimeError: -c import golang;from dsouser import test; test.main() E (failed) golang/golang_test.py:1703: RuntimeError ------------------------------------ Captured stdout call ------------------------------------ running build_dso Building DSOs building 'dsouser.dso' DSO as build/lib.macosx-10.15-x86_64-3.7/dsouser/libdso.dylib creating build creating build/temp.macosx-10.15-x86_64-3.7 creating build/temp.macosx-10.15-x86_64-3.7/dsouser clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers -I/Users/kirr/pygolang -c dsouser/dso.cpp -o build/temp.macosx-10.15-x86_64-3.7/dsouser/dso.o -std=c++11 -fno-strict-aliasing creating build/lib.macosx-10.15-x86_64-3.7 creating build/lib.macosx-10.15-x86_64-3.7/dsouser clang++ -dynamiclib -undefined dynamic_lookup build/temp.macosx-10.15-x86_64-3.7/dsouser/dso.o -L/Users/kirr/pygolang/golang/runtime -llibgolang -o build/lib.macosx-10.15-x86_64-3.7/dsouser/libdso.dylib -install_name @loader_path/libdso.dylib otool -L build/lib.macosx-10.15-x86_64-3.7/dsouser/libdso.dylib build/lib.macosx-10.15-x86_64-3.7/dsouser/libdso.dylib: @loader_path/libdso.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/liblibgolang.0.1.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) install_name_tool -change @loader_path/liblibgolang.0.1.dylib @loader_path/../golang/runtime/liblibgolang.0.1.dylib build/lib.macosx-10.15-x86_64-3.7/dsouser/libdso.dylib otool -L build/lib.macosx-10.15-x86_64-3.7/dsouser/libdso.dylib build/lib.macosx-10.15-x86_64-3.7/dsouser/libdso.dylib: @loader_path/libdso.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/../golang/runtime/liblibgolang.0.1.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) copying build/lib.macosx-10.15-x86_64-3.7/dsouser/libdso.dylib -> dsouser running build_ext cythoning dsouser/test.pyx to dsouser/test.cpp building 'dsouser.test' extension clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers -I/Users/kirr/pygolang -I/Users/kirr/py3.venv/bin/../include/site/python3.7 -I/usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/include/python3.7m -c dsouser/test.cpp -o build/temp.macosx-10.15-x86_64-3.7/dsouser/test.o -std=c++11 -fno-strict-aliasing clang++ -bundle -undefined dynamic_lookup build/temp.macosx-10.15-x86_64-3.7/dsouser/test.o -L/Users/kirr/pygolang/golang/runtime -Lbuild/lib.macosx-10.15-x86_64-3.7/dsouser -llibgolang -ldso -o build/lib.macosx-10.15-x86_64-3.7/dsouser/test.cpython-37m-darwin.so otool -L build/lib.macosx-10.15-x86_64-3.7/dsouser/test.cpython-37m-darwin.so build/lib.macosx-10.15-x86_64-3.7/dsouser/test.cpython-37m-darwin.so: @loader_path/liblibgolang.0.1.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libdso.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) install_name_tool -change @loader_path/liblibgolang.0.1.dylib @loader_path/../golang/runtime/liblibgolang.0.1.dylib build/lib.macosx-10.15-x86_64-3.7/dsouser/test.cpython-37m-darwin.so install_name_tool -change @loader_path/libdso.dylib @loader_path/./libdso.dylib build/lib.macosx-10.15-x86_64-3.7/dsouser/test.cpython-37m-darwin.so otool -L build/lib.macosx-10.15-x86_64-3.7/dsouser/test.cpython-37m-darwin.so build/lib.macosx-10.15-x86_64-3.7/dsouser/test.cpython-37m-darwin.so: @loader_path/../golang/runtime/liblibgolang.0.1.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/./libdso.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) copying build/lib.macosx-10.15-x86_64-3.7/dsouser/test.cpython-37m-darwin.so -> dsouser ------------------------------------ Captured stderr call ------------------------------------ Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: dlopen(/Users/kirr/pygolang/golang/pyx/testprog/golang_dso_user/dsouser/test.cpython-37m-darwin.so, 2): Library not loaded: @loader_path/../golang/runtime/liblibgolang.0.1.dylib Referenced from: /Users/kirr/pygolang/golang/pyx/testprog/golang_dso_user/dsouser/test.cpython-37m-darwin.so Reason: image not found ========================== 2 failed, 94 passed, 4 skipped in 20.26s ==========================
-
Kirill Smelkov authored
qq is used to quote strings or byte-strings. The following example illustrates the problem we are currently hitting in zodbtools with Python3: >>> "hello %s" % qq("мир") 'hello "мир"' >>> b"hello %s" % qq("мир") Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'str' >>> "hello %s" % qq(b("мир")) 'hello "мир"' >>> b"hello %s" % qq(b("мир")) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'str' i.e. one way or another if type of format string and what qq returns do not match it creates a TypeError. We want qq(obj) to be useable with both string and bytestring format. For that let's teach qq to return special str- and bytes- derived types that know how to automatically convert to str->bytes and bytes->str via b/u correspondingly. This way formatting works whatever types combination it was for format and for qq, and the whole result has the same type as format. For now we teach only qq to use new types and don't generally expose _str and _unicode to be returned by b and u yet. However we might do so in the future after incrementally gaining a bit more experience. /proposed-for-review-on: !1
-
- 29 Apr, 2020 1 commit
-
-
Kirill Smelkov authored
i.e. unicode on py3 and bytes on py2. This makes it more likely to work for "format string %s ..." % qq(object) with format string being str and object of arbitrary type. However more on this topic in the next patch.
-