From memedough at gmail.com Mon Jul 5 12:17:52 2010 From: memedough at gmail.com (meme dough) Date: Mon, 5 Jul 2010 20:17:52 +1000 Subject: [py-dev] pytest-cov multiple reports poll Message-ID: Hi, When I first wrote pytest-cov I thought that when dist=each it should output a coverage report for each slave. However it seems that people want it to combine so they can see the overall coverage. I am thinking of removing it to make it simpler and just always combine and produce single report for both dist=load and dist=each. Would anyone not want this to happen? :) From holger at merlinux.eu Mon Jul 5 12:38:17 2010 From: holger at merlinux.eu (holger krekel) Date: Mon, 5 Jul 2010 12:38:17 +0200 Subject: [py-dev] pytest-cov multiple reports poll In-Reply-To: References: Message-ID: <20100705103817.GK14601@trillke.net> Hi Meme, On Mon, Jul 05, 2010 at 20:17 +1000, meme dough wrote: > Hi, > > When I first wrote pytest-cov I thought that when dist=each it should > output a coverage report for each slave. > > However it seems that people want it to combine so they can see the > overall coverage. > > I am thinking of removing it to make it simpler and just always > combine and produce single report for both dist=load and dist=each. > > Would anyone not want this to happen? > > :) Not sure about the potential double negation - i think it makes sense to always combine reports. It's still possible to get target-specific coverage for a --dist-each situation by just specifying a single-target run. And for --dist=load it hardly makes sense to have separate random coverage. best, holger From prologic at shortcircuit.net.au Thu Jul 8 14:36:04 2010 From: prologic at shortcircuit.net.au (James Mills) Date: Thu, 8 Jul 2010 22:36:04 +1000 Subject: [py-dev] pytest-cov Message-ID: Hi, ~/circuits $ make clean tests ============================= test session starts ============================== platform linux2 -- Python 2.6.5 -- pytest-1.3.1 -- /home/prologic/bin/python test object 1: tests/ [gw0] popen//python=/usr/bin/python2.5 -- platform linux2, Python 2.5.5-final-0 cwd: /home/prologic/work/circuits [gw1] popen//python=/usr/bin/python2.6 -- platform linux2, Python 2.6.5-final-0 cwd: /home/prologic/work/circuits [master] starting full item collection ... /home/prologic/work/circuits/circuits/net/sockets.py:22: UserWarning: No SSL support available. Using python-2.5 ? Try isntalling the ssl module: http://pypi.python.org/pypi/ssl/ warnings.warn("No SSL support available. Using python-2.5 ? Try isntalling the ssl module: http://pypi.python.org/pypi/ssl/") [master] collected 154 items [gw0] txnode ready to receive tests [gw1] txnode ready to receive tests tests/app/test_daemon.py FException in thread App (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner File "/usr/lib/python2.6/threading.py", line 484, in run File "/home/prologic/work/circuits/circuits/core/manager.py", line 539, in run File "/home/prologic/work/circuits/circuits/core/manager.py", line 124, in __len__ : 'NoneType' object is not callable Exception in thread App (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner File "/usr/lib/python2.5/threading.py", line 446, in run File "/home/prologic/work/circuits/circuits/core/manager.py", line 539, in run File "/home/prologic/work/circuits/circuits/core/manager.py", line 124, in __len__ : 'NoneType' object is not callable =================================== FAILURES =================================== _____________________________________ test _____________________________________ [gw1] popen//python=/usr/bin/python2.6 -- platform linux2, Python 2.6.5-final-0 tmpdir = local('/tmp/pytest-76/popen/slave-1/test0') cov = def test(tmpdir, cov): tmpdir.ensure("app.pid") pidpath = tmpdir.join("app.pid") pidfile = str(pidpath) args = ["python", app.__file__, pidfile] cmd = " ".join(args) p = Popen(cmd, shell=True) status = p.wait() > assert status == 0 E assert 1 == 0 tests/app/test_daemon.py:19: AssertionError ------------------------------- Captured stderr -------------------------------- RuntimeError: Bad magic number in .pyc file =========================== short test summary info ============================ FAIL tests/app/test_daemon.py::test !!!!!!!!!!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!!!!!!!!!! ========================== 1 failed in 20.36 seconds =========================== pastebin session-log: http://paste.pocoo.org/show/234968 make: *** [tests] Error 2 The above ^^^ is a sample test run of my project circuits (1) Because I don't have anything more to add I'll just paste/show it here and ask if anyone has any thoughts... >From what I can tell the xdist plugin might have to re-compile the .pyc files in question (or something). I'm not sure :) cheers James -- -- James Mills -- -- "Problems are solved by method" From holger at merlinux.eu Thu Jul 8 14:40:23 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 8 Jul 2010 14:40:23 +0200 Subject: [py-dev] pytest-cov In-Reply-To: References: Message-ID: <20100708124022.GP14601@trillke.net> Hi James, does it help if you set the environment variable PYTHONDOWNWRITEBYTECODE=1 before invoking your tests? (i think python2.5 does not support it but a python2.6/python2.5 run should not intermingle wrt to pyc files anymore) holger On Thu, Jul 08, 2010 at 22:36 +1000, James Mills wrote: > Hi, > > ~/circuits > $ make clean tests > ============================= test session starts ============================== > platform linux2 -- Python 2.6.5 -- pytest-1.3.1 -- /home/prologic/bin/python > test object 1: tests/ > [gw0] popen//python=/usr/bin/python2.5 -- platform linux2, Python > 2.5.5-final-0 cwd: /home/prologic/work/circuits > [gw1] popen//python=/usr/bin/python2.6 -- platform linux2, Python > 2.6.5-final-0 cwd: /home/prologic/work/circuits > [master] starting full item collection ... > /home/prologic/work/circuits/circuits/net/sockets.py:22: UserWarning: > No SSL support available. Using python-2.5 ? Try isntalling the ssl > module: http://pypi.python.org/pypi/ssl/ > warnings.warn("No SSL support available. Using python-2.5 ? Try > isntalling the ssl module: http://pypi.python.org/pypi/ssl/") > [master] collected 154 items > [gw0] txnode ready to receive tests > [gw1] txnode ready to receive tests > > tests/app/test_daemon.py FException in thread App (most likely raised > during interpreter shutdown): > Traceback (most recent call last): > File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner > File "/usr/lib/python2.6/threading.py", line 484, in run > File "/home/prologic/work/circuits/circuits/core/manager.py", line 539, in run > File "/home/prologic/work/circuits/circuits/core/manager.py", line > 124, in __len__ > : 'NoneType' object is not callable > Exception in thread App (most likely raised during interpreter shutdown): > Traceback (most recent call last): > File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner > File "/usr/lib/python2.5/threading.py", line 446, in run > File "/home/prologic/work/circuits/circuits/core/manager.py", line 539, in run > File "/home/prologic/work/circuits/circuits/core/manager.py", line > 124, in __len__ > : 'NoneType' object is not callable > > > =================================== FAILURES =================================== > _____________________________________ test _____________________________________ > [gw1] popen//python=/usr/bin/python2.6 -- platform linux2, Python 2.6.5-final-0 > > tmpdir = local('/tmp/pytest-76/popen/slave-1/test0') > cov = > > def test(tmpdir, cov): > tmpdir.ensure("app.pid") > pidpath = tmpdir.join("app.pid") > pidfile = str(pidpath) > > args = ["python", app.__file__, pidfile] > cmd = " ".join(args) > p = Popen(cmd, shell=True) > status = p.wait() > > > assert status == 0 > E assert 1 == 0 > > tests/app/test_daemon.py:19: AssertionError > ------------------------------- Captured stderr -------------------------------- > RuntimeError: Bad magic number in .pyc file > =========================== short test summary info ============================ > FAIL tests/app/test_daemon.py::test > !!!!!!!!!!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!!!!!!!!!! > ========================== 1 failed in 20.36 seconds =========================== > pastebin session-log: http://paste.pocoo.org/show/234968 > make: *** [tests] Error 2 > > > The above ^^^ is a sample test run of my project circuits (1) > > Because I don't have anything more to add I'll just paste/show > it here and ask if anyone has any thoughts... > > >From what I can tell the xdist plugin might have to re-compile > the .pyc files in question (or something). I'm not sure :) > > cheers > James > > > -- > -- James Mills > -- > -- "Problems are solved by method" > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From prologic at shortcircuit.net.au Thu Jul 8 14:44:50 2010 From: prologic at shortcircuit.net.au (James Mills) Date: Thu, 8 Jul 2010 22:44:50 +1000 Subject: [py-dev] pytest-cov In-Reply-To: <20100708124022.GP14601@trillke.net> References: <20100708124022.GP14601@trillke.net> Message-ID: On Thu, Jul 8, 2010 at 10:40 PM, holger krekel wrote: > does it help if you set the environment variable > PYTHONDOWNWRITEBYTECODE=1 No, this didn't seem to affect anything. cheers James -- -- James Mills -- -- "Problems are solved by method" From holger at merlinux.eu Thu Jul 8 17:31:35 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 8 Jul 2010 17:31:35 +0200 Subject: [py-dev] py.test 1.3.2: API and reporting refinements & fixes Message-ID: <20100708153135.GQ14601@trillke.net> The pylib/py.test 1.3.2 release brings many bug fixes and some new features. It was refined for and tested against the recently released Python2.7 and remains compatibile to the usual armada of interpreters (Python2.4 through to Python3.1.2, Jython and PyPy). Note that for using distributed testing features you'll need to upgrade to the jointly released pytest-xdist-1.4 because of some internal refactorings. See http://pytest.org for general documentation and below for a inlined detailed CHANGELOG. cheers & particular thanks to Benjamin Peterson, Ronny Pfannschmidt and all issue and patch contributors, holger krekel Changes between 1.3.1 and 1.3.2 ================================================== New features ++++++++++++++++++ - fix issue103: introduce py.test.raises as context manager, examples:: with py.test.raises(ZeroDivisionError): x = 0 1 / x with py.test.raises(RuntimeError) as excinfo: call_something() # you may do extra checks on excinfo.value|type|traceback here (thanks Ronny Pfannschmidt) - Funcarg factories can now dynamically apply a marker to a test invocation. This is for example useful if a factory provides parameters to a test which are expected-to-fail:: def pytest_funcarg__arg(request): request.applymarker(py.test.mark.xfail(reason="flaky config")) ... def test_function(arg): ... - improved error reporting on collection and import errors. This makes use of a more general mechanism, namely that for custom test item/collect nodes ``node.repr_failure(excinfo)`` is now uniformly called so that you can override it to return a string error representation of your choice which is going to be reported as a (red) string. - introduce '--junitprefix=STR' option to prepend a prefix to all reports in the junitxml file. Bug fixes / Maintenance ++++++++++++++++++++++++++ - make tests and the ``pytest_recwarn`` plugin in particular fully compatible to Python2.7 (if you use the ``recwarn`` funcarg warnings will be enabled so that you can properly check for their existence in a cross-python manner). - refine --pdb: ignore xfailed tests, unify its TB-reporting and don't display failures again at the end. - fix assertion interpretation with the ** operator (thanks Benjamin Peterson) - fix issue105 assignment on the same line as a failing assertion (thanks Benjamin Peterson) - fix issue104 proper escaping for test names in junitxml plugin (thanks anonymous) - fix issue57 -f|--looponfail to work with xpassing tests (thanks Ronny) - fix issue92 collectonly reporter and --pastebin (thanks Benjamin Peterson) - fix py.code.compile(source) to generate unique filenames - fix assertion re-interp problems on PyPy, by defering code compilation to the (overridable) Frame.eval class. (thanks Amaury Forgeot) - fix py.path.local.pyimport() to work with directories - streamline py.path.local.mkdtemp implementation and usage - don't print empty lines when showing junitxml-filename - add optional boolean ignore_errors parameter to py.path.local.remove - fix terminal writing on win32/python2.4 - py.process.cmdexec() now tries harder to return properly encoded unicode objects on all python versions - install plain py.test/py.which scripts also for Jython, this helps to get canonical script paths in virtualenv situations - make path.bestrelpath(path) return ".", note that when calling X.bestrelpath the assumption is that X is a directory. - make initial conftest discovery ignore "--" prefixed arguments - fix resultlog plugin when used in an multicpu/multihost xdist situation (thanks Jakub Gustak) - perform distributed testing related reporting in the xdist-plugin rather than having dist-related code in the generic py.test distribution - fix homedir detection on Windows - ship distribute_setup.py version 0.6.13 Changes between 1.3.0 and 1.3.1 ================================================== New features ++++++++++++++++++ - issue91: introduce new py.test.xfail(reason) helper to imperatively mark a test as expected to fail. Can be used from within setup and test functions. This is useful especially for parametrized tests when certain configurations are expected-to-fail. In this case the declarative approach with the @py.test.mark.xfail cannot be used as it would mark all configurations as xfail. - issue102: introduce new --maxfail=NUM option to stop test runs after NUM failures. This is a generalization of the '-x' or '--exitfirst' option which is now equivalent to '--maxfail=1'. Both '-x' and '--maxfail' will now also print a line near the end indicating the Interruption. - issue89: allow py.test.mark decorators to be used on classes (class decorators were introduced with python2.6) and also allow to have multiple markers applied at class/module level by specifying a list. - improve and refine letter reporting in the progress bar: . pass f failed test s skipped tests (reminder: use for dependency/platform mismatch only) x xfailed test (test that was expected to fail) X xpassed test (test that was expected to fail but passed) You can use any combination of 'fsxX' with the '-r' extended reporting option. The xfail/xpass results will show up as skipped tests in the junitxml output - which also fixes issue99. - make py.test.cmdline.main() return the exitstatus instead of raising SystemExit and also allow it to be called multiple times. This of course requires that your application and tests are properly teared down and don't have global state. Fixes / Maintenance ++++++++++++++++++++++ - improved traceback presentation: - improved and unified reporting for "--tb=short" option - Errors during test module imports are much shorter, (using --tb=short style) - raises shows shorter more relevant tracebacks - --fulltrace now more systematically makes traces longer / inhibits cutting - improve support for raises and other dynamically compiled code by manipulating python's linecache.cache instead of the previous rather hacky way of creating custom code objects. This makes it seemlessly work on Jython and PyPy where it previously didn't. - fix issue96: make capturing more resilient against Control-C interruptions (involved somewhat substantial refactoring to the underlying capturing functionality to avoid race conditions). - fix chaining of conditional skipif/xfail decorators - so it works now as expected to use multiple @py.test.mark.skipif(condition) decorators, including specific reporting which of the conditions lead to skipping. - fix issue95: late-import zlib so that it's not required for general py.test startup. - fix issue94: make reporting more robust against bogus source code (and internally be more careful when presenting unexpected byte sequences) Changes between 1.2.1 and 1.3.0 ================================================== - deprecate --report option in favour of a new shorter and easier to remember -r option: it takes a string argument consisting of any combination of 'xfsX' characters. They relate to the single chars you see during the dotted progress printing and will print an extra line per test at the end of the test run. This extra line indicates the exact position or test ID that you directly paste to the py.test cmdline in order to re-run a particular test. - allow external plugins to register new hooks via the new pytest_addhooks(pluginmanager) hook. The new release of the pytest-xdist plugin for distributed and looponfailing testing requires this feature. - add a new pytest_ignore_collect(path, config) hook to allow projects and plugins to define exclusion behaviour for their directory structure - for example you may define in a conftest.py this method:: def pytest_ignore_collect(path): return path.check(link=1) to prevent even a collection try of any tests in symlinked dirs. - new pytest_pycollect_makemodule(path, parent) hook for allowing customization of the Module collection object for a matching test module. - extend and refine xfail mechanism: ``@py.test.mark.xfail(run=False)`` do not run the decorated test ``@py.test.mark.xfail(reason="...")`` prints the reason string in xfail summaries specifiying ``--runxfail`` on command line virtually ignores xfail markers - expose (previously internal) commonly useful methods: py.io.get_terminal_with() -> return terminal width py.io.ansi_print(...) -> print colored/bold text on linux/win32 py.io.saferepr(obj) -> return limited representation string - expose test outcome related exceptions as py.test.skip.Exception, py.test.raises.Exception etc., useful mostly for plugins doing special outcome interpretation/tweaking - (issue85) fix junitxml plugin to handle tests with non-ascii output - fix/refine python3 compatibility (thanks Benjamin Peterson) - fixes for making the jython/win32 combination work, note however: jython2.5.1/win32 does not provide a command line launcher, see http://bugs.jython.org/issue1491 . See pylib install documentation for how to work around. - fixes for handling of unicode exception values and unprintable objects - (issue87) fix unboundlocal error in assertionold code - (issue86) improve documentation for looponfailing - refine IO capturing: stdin-redirect pseudo-file now has a NOP close() method - ship distribute_setup.py version 0.6.10 - added links to the new capturelog and coverage plugins Changes between 1.2.1 and 1.2.0 ===================================== - refined usage and options for "py.cleanup":: py.cleanup # remove "*.pyc" and "*$py.class" (jython) files py.cleanup -e .swp -e .cache # also remove files with these extensions py.cleanup -s # remove "build" and "dist" directory next to setup.py files py.cleanup -d # also remove empty directories py.cleanup -a # synonym for "-s -d -e 'pip-log.txt'" py.cleanup -n # dry run, only show what would be removed - add a new option "py.test --funcargs" which shows available funcargs and their help strings (docstrings on their respective factory function) for a given test path - display a short and concise traceback if a funcarg lookup fails - early-load "conftest.py" files in non-dot first-level sub directories. allows to conveniently keep and access test-related options in a ``test`` subdir and still add command line options. - fix issue67: new super-short traceback-printing option: "--tb=line" will print a single line for each failing (python) test indicating its filename, lineno and the failure value - fix issue78: always call python-level teardown functions even if the according setup failed. This includes refinements for calling setup_module/class functions which will now only be called once instead of the previous behaviour where they'd be called multiple times if they raise an exception (including a Skipped exception). Any exception will be re-corded and associated with all tests in the according module/class scope. - fix issue63: assume <40 columns to be a bogus terminal width, default to 80 - fix pdb debugging to be in the correct frame on raises-related errors - update apipkg.py to fix an issue where recursive imports might unnecessarily break importing - fix plugin links Changes between 1.2 and 1.1.1 ===================================== - moved dist/looponfailing from py.test core into a new separately released pytest-xdist plugin. - new junitxml plugin: --junitxml=path will generate a junit style xml file which is processable e.g. by the Hudson CI system. - new option: --genscript=path will generate a standalone py.test script which will not need any libraries installed. thanks to Ralf Schmitt. - new option: --ignore will prevent specified path from collection. Can be specified multiple times. - new option: --confcutdir=dir will make py.test only consider conftest files that are relative to the specified dir. - new funcarg: "pytestconfig" is the pytest config object for access to command line args and can now be easily used in a test. - install 'py.test' and `py.which` with a ``-$VERSION`` suffix to disambiguate between Python3, python2.X, Jython and PyPy installed versions. - new "pytestconfig" funcarg allows access to test config object - new "pytest_report_header" hook can return additional lines to be displayed at the header of a test run. - (experimental) allow "py.test path::name1::name2::..." for pointing to a test within a test collection directly. This might eventually evolve as a full substitute to "-k" specifications. - streamlined plugin loading: order is now as documented in customize.html: setuptools, ENV, commandline, conftest. also setuptools entry point names are turned to canonical namees ("pytest_*") - automatically skip tests that need 'capfd' but have no os.dup - allow pytest_generate_tests to be defined in classes as well - deprecate usage of 'disabled' attribute in favour of pytestmark - deprecate definition of Directory, Module, Class and Function nodes in conftest.py files. Use pytest collect hooks instead. - collection/item node specific runtest/collect hooks are only called exactly on matching conftest.py files, i.e. ones which are exactly below the filesystem path of an item - change: the first pytest_collect_directory hook to return something will now prevent further hooks to be called. - change: figleaf plugin now requires --figleaf to run. Also change its long command line options to be a bit shorter (see py.test -h). - change: pytest doctest plugin is now enabled by default and has a new option --doctest-glob to set a pattern for file matches. - change: remove internal py._* helper vars, only keep py._pydir - robustify capturing to survive if custom pytest_runtest_setup code failed and prevented the capturing setup code from running. - make py.test.* helpers provided by default plugins visible early - works transparently both for pydoc and for interactive sessions which will regularly see e.g. py.test.mark and py.test.importorskip. - simplify internal plugin manager machinery - simplify internal collection tree by introducing a RootCollector node - fix assert reinterpreation that sees a call containing "keyword=..." - fix issue66: invoke pytest_sessionstart and pytest_sessionfinish hooks on slaves during dist-testing, report module/session teardown hooks correctly. - fix issue65: properly handle dist-testing if no execnet/py lib installed remotely. - skip some install-tests if no execnet is available - fix docs, fix internal bin/ script generation Changes between 1.1.1 and 1.1.0 ===================================== - introduce automatic plugin registration via 'pytest11' entrypoints via setuptools' pkg_resources.iter_entry_points - fix py.test dist-testing to work with execnet >= 1.0.0b4 - re-introduce py.test.cmdline.main() for better backward compatibility - svn paths: fix a bug with path.check(versioned=True) for svn paths, allow '%' in svn paths, make svnwc.update() default to interactive mode like in 1.0.x and add svnwc.update(interactive=False) to inhibit interaction. - refine distributed tarball to contain test and no pyc files - try harder to have deprecation warnings for py.compat.* accesses report a correct location Changes between 1.1.0 and 1.0.2 ===================================== * adjust and improve docs * remove py.rest tool and internal namespace - it was never really advertised and can still be used with the old release if needed. If there is interest it could be revived into its own tool i guess. * fix issue48 and issue59: raise an Error if the module from an imported test file does not seem to come from the filepath - avoids "same-name" confusion that has been reported repeatedly * merged Ronny's nose-compatibility hacks: now nose-style setup_module() and setup() functions are supported * introduce generalized py.test.mark function marking * reshuffle / refine command line grouping * deprecate parser.addgroup in favour of getgroup which creates option group * add --report command line option that allows to control showing of skipped/xfailed sections * generalized skipping: a new way to mark python functions with skipif or xfail at function, class and modules level based on platform or sys-module attributes. * extend py.test.mark decorator to allow for positional args * introduce and test "py.cleanup -d" to remove empty directories * fix issue #59 - robustify unittest test collection * make bpython/help interaction work by adding an __all__ attribute to ApiModule, cleanup initpkg * use MIT license for pylib, add some contributors * remove py.execnet code and substitute all usages with 'execnet' proper * fix issue50 - cached_setup now caches more to expectations for test functions with multiple arguments. * merge Jarko's fixes, issue #45 and #46 * add the ability to specify a path for py.lookup to search in * fix a funcarg cached_setup bug probably only occuring in distributed testing and "module" scope with teardown. * many fixes and changes for making the code base python3 compatible, many thanks to Benjamin Peterson for helping with this. * consolidate builtins implementation to be compatible with >=2.3, add helpers to ease keeping 2 and 3k compatible code * deprecate py.compat.doctest|subprocess|textwrap|optparse * deprecate py.magic.autopath, remove py/magic directory * move pytest assertion handling to py/code and a pytest_assertion plugin, add "--no-assert" option, deprecate py.magic namespaces in favour of (less) py.code ones. * consolidate and cleanup py/code classes and files * cleanup py/misc, move tests to bin-for-dist * introduce delattr/delitem/delenv methods to py.test's monkeypatch funcarg * consolidate py.log implementation, remove old approach. * introduce py.io.TextIO and py.io.BytesIO for distinguishing between text/unicode and byte-streams (uses underlying standard lib io.* if available) * make py.unittest_convert helper script available which converts "unittest.py" style files into the simpler assert/direct-test-classes py.test/nosetests style. The script was written by Laura Creighton. * simplified internal localpath implementation Changes between 1.0.1 and 1.0.2 ===================================== * fixing packaging issues, triggered by fedora redhat packaging, also added doc, examples and contrib dirs to the tarball. * added a documentation link to the new django plugin. Changes between 1.0.0 and 1.0.1 ===================================== * added a 'pytest_nose' plugin which handles nose.SkipTest, nose-style function/method/generator setup/teardown and tries to report functions correctly. * capturing of unicode writes or encoded strings to sys.stdout/err work better, also terminalwriting was adapted and somewhat unified between windows and linux. * improved documentation layout and content a lot * added a "--help-config" option to show conftest.py / ENV-var names for all longopt cmdline options, and some special conftest.py variables. renamed 'conf_capture' conftest setting to 'option_capture' accordingly. * fix issue #27: better reporting on non-collectable items given on commandline (e.g. pyc files) * fix issue #33: added --version flag (thanks Benjamin Peterson) * fix issue #32: adding support for "incomplete" paths to wcpath.status() * "Test" prefixed classes are *not* collected by default anymore if they have an __init__ method * monkeypatch setenv() now accepts a "prepend" parameter * improved reporting of collection error tracebacks * simplified multicall mechanism and plugin architecture, renamed some internal methods and argnames Changes between 1.0.0b9 and 1.0.0 ===================================== * more terse reporting try to show filesystem path relatively to current dir * improve xfail output a bit Changes between 1.0.0b8 and 1.0.0b9 ===================================== * cleanly handle and report final teardown of test setup * fix svn-1.6 compat issue with py.path.svnwc().versioned() (thanks Wouter Vanden Hove) * setup/teardown or collection problems now show as ERRORs or with big "E"'s in the progress lines. they are reported and counted separately. * dist-testing: properly handle test items that get locally collected but cannot be collected on the remote side - often due to platform/dependency reasons * simplified py.test.mark API - see keyword plugin documentation * integrate better with logging: capturing now by default captures test functions and their immediate setup/teardown in a single stream * capsys and capfd funcargs now have a readouterr() and a close() method (underlyingly py.io.StdCapture/FD objects are used which grew a readouterr() method as well to return snapshots of captured out/err) * make assert-reinterpretation work better with comparisons not returning bools (reported with numpy from thanks maciej fijalkowski) * reworked per-test output capturing into the pytest_iocapture.py plugin and thus removed capturing code from config object * item.repr_failure(excinfo) instead of item.repr_failure(excinfo, outerr) Changes between 1.0.0b7 and 1.0.0b8 ===================================== * pytest_unittest-plugin is now enabled by default * introduced pytest_keyboardinterrupt hook and refined pytest_sessionfinish hooked, added tests. * workaround a buggy logging module interaction ("closing already closed files"). Thanks to Sridhar Ratnakumar for triggering. * if plugins use "py.test.importorskip" for importing a dependency only a warning will be issued instead of exiting the testing process. * many improvements to docs: - refined funcargs doc , use the term "factory" instead of "provider" - added a new talk/tutorial doc page - better download page - better plugin docstrings - added new plugins page and automatic doc generation script * fixed teardown problem related to partially failing funcarg setups (thanks MrTopf for reporting), "pytest_runtest_teardown" is now always invoked even if the "pytest_runtest_setup" failed. * tweaked doctest output for docstrings in py modules, thanks Radomir. Changes between 1.0.0b3 and 1.0.0b7 ============================================= * renamed py.test.xfail back to py.test.mark.xfail to avoid two ways to decorate for xfail * re-added py.test.mark decorator for setting keywords on functions (it was actually documented so removing it was not nice) * remove scope-argument from request.addfinalizer() because request.cached_setup has the scope arg. TOOWTDI. * perform setup finalization before reporting failures * apply modified patches from Andreas Kloeckner to allow test functions to have no func_code (#22) and to make "-k" and function keywords work (#20) * apply patch from Daniel Peolzleithner (issue #23) * resolve issue #18, multiprocessing.Manager() and redirection clash * make __name__ == "__channelexec__" for remote_exec code Changes between 1.0.0b1 and 1.0.0b3 ============================================= * plugin classes are removed: one now defines hooks directly in conftest.py or global pytest_*.py files. * added new pytest_namespace(config) hook that allows to inject helpers directly to the py.test.* namespace. * documented and refined many hooks * added new style of generative tests via pytest_generate_tests hook that integrates well with function arguments. Changes between 0.9.2 and 1.0.0b1 ============================================= * introduced new "funcarg" setup method, see doc/test/funcarg.txt * introduced plugin architecuture and many new py.test plugins, see doc/test/plugins.txt * teardown_method is now guaranteed to get called after a test method has run. * new method: py.test.importorskip(mod,minversion) will either import or call py.test.skip() * completely revised internal py.test architecture * new py.process.ForkedFunc object allowing to fork execution of a function to a sub process and getting a result back. XXX lots of things missing here XXX Changes between 0.9.1 and 0.9.2 =============================== * refined installation and metadata, created new setup.py, now based on setuptools/ez_setup (thanks to Ralf Schmitt for his support). * improved the way of making py.* scripts available in windows environments, they are now added to the Scripts directory as ".cmd" files. * py.path.svnwc.status() now is more complete and uses xml output from the 'svn' command if available (Guido Wesdorp) * fix for py.path.svn* to work with svn 1.5 (Chris Lamb) * fix path.relto(otherpath) method on windows to use normcase for checking if a path is relative. * py.test's traceback is better parseable from editors (follows the filenames:LINENO: MSG convention) (thanks to Osmo Salomaa) * fix to javascript-generation, "py.test --runbrowser" should work more reliably now * removed previously accidentally added py.test.broken and py.test.notimplemented helpers. * there now is a py.__version__ attribute Changes between 0.9.0 and 0.9.1 =============================== This is a fairly complete list of changes between 0.9 and 0.9.1, which can serve as a reference for developers. * allowing + signs in py.path.svn urls [39106] * fixed support for Failed exceptions without excinfo in py.test [39340] * added support for killing processes for Windows (as well as platforms that support os.kill) in py.misc.killproc [39655] * added setup/teardown for generative tests to py.test [40702] * added detection of FAILED TO LOAD MODULE to py.test [40703, 40738, 40739] * fixed problem with calling .remove() on wcpaths of non-versioned files in py.path [44248] * fixed some import and inheritance issues in py.test [41480, 44648, 44655] * fail to run greenlet tests when pypy is available, but without stackless [45294] * small fixes in rsession tests [45295] * fixed issue with 2.5 type representations in py.test [45483, 45484] * made that internal reporting issues displaying is done atomically in py.test [45518] * made that non-existing files are igored by the py.lookup script [45519] * improved exception name creation in py.test [45535] * made that less threads are used in execnet [merge in 45539] * removed lock required for atomical reporting issue displaying in py.test [45545] * removed globals from execnet [45541, 45547] * refactored cleanup mechanics, made that setDaemon is set to 1 to make atexit get called in 2.5 (py.execnet) [45548] * fixed bug in joining threads in py.execnet's servemain [45549] * refactored py.test.rsession tests to not rely on exact output format anymore [45646] * using repr() on test outcome [45647] * added 'Reason' classes for py.test.skip() [45648, 45649] * killed some unnecessary sanity check in py.test.collect [45655] * avoid using os.tmpfile() in py.io.fdcapture because on Windows it's only usable by Administrators [45901] * added support for locking and non-recursive commits to py.path.svnwc [45994] * locking files in py.execnet to prevent CPython from segfaulting [46010] * added export() method to py.path.svnurl * fixed -d -x in py.test [47277] * fixed argument concatenation problem in py.path.svnwc [49423] * restore py.test behaviour that it exits with code 1 when there are failures [49974] * don't fail on html files that don't have an accompanying .txt file [50606] * fixed 'utestconvert.py < input' [50645] * small fix for code indentation in py.code.source [50755] * fix _docgen.py documentation building [51285] * improved checks for source representation of code blocks in py.test [51292] * added support for passing authentication to py.path.svn* objects [52000, 52001] * removed sorted() call for py.apigen tests in favour of [].sort() to support Python 2.3 [52481] From memedough at gmail.com Fri Jul 9 10:39:16 2010 From: memedough at gmail.com (meme dough) Date: Fri, 9 Jul 2010 18:39:16 +1000 Subject: [py-dev] pytest-cov In-Reply-To: References: <20100708124022.GP14601@trillke.net> Message-ID: Hi, Did you try deleting all .pyc and .pyo files in /home/prologic/work/circuits recursively and then trying? Since it looks like python 2.6 will create the pyc files in the master process and then the popen to python 2.5 barfs on them. As Holger pointed out PYTHONDOWNWRITEBYTECODE should turn off the master python 2.6 creating pyc files. But if you've still got old ones lying around then the slave python 2.5 will no doubt barf. Another solution to this maybe to give each test process it's own area. So change the working dir of each tx and specify the rsync option to get the proper code to each test area (I assume the rsync doesn't push pyc files). Also that way if your code relies on it's own resources in the dir tree (writing out to a log file for example) then they will be separate and not clash. :) On 8 July 2010 22:44, James Mills wrote: > On Thu, Jul 8, 2010 at 10:40 PM, holger krekel wrote: >> does it help if you set the environment variable >> PYTHONDOWNWRITEBYTECODE=1 > > No, this didn't seem to affect anything. > > cheers > James > > > -- > -- James Mills > -- > -- "Problems are solved by method" > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > From prologic at shortcircuit.net.au Fri Jul 9 10:55:53 2010 From: prologic at shortcircuit.net.au (James Mills) Date: Fri, 9 Jul 2010 18:55:53 +1000 Subject: [py-dev] pytest-cov In-Reply-To: References: <20100708124022.GP14601@trillke.net> Message-ID: On Fri, Jul 9, 2010 at 6:39 PM, meme dough wrote: > Did you try deleting all .pyc and .pyo files in > /home/prologic/work/circuits recursively and then trying? Yes, tried and same result. > Since it looks like python 2.6 will create the pyc files in the master > process and then the popen to python 2.5 barfs on them. ?As Holger > pointed out PYTHONDOWNWRITEBYTECODE should turn off the master python > 2.6 creating pyc files. ?But if you've still got old ones lying around > then the slave python 2.5 will no doubt barf. Also tried, same result. > Another solution to this maybe to give each test process it's own > area. ?So change the working dir of each tx and specify the rsync > option to get the proper code to each test area (I assume the rsync > doesn't push pyc files). ?Also that way if your code relies on it's > own resources in the dir tree (writing out to a log file for example) > then they will be separate and not clash. Could you show an example tx config that does thsi ? cheers James -- -- James Mills -- -- "Problems are solved by method" From prologic at shortcircuit.net.au Fri Jul 9 10:57:30 2010 From: prologic at shortcircuit.net.au (James Mills) Date: Fri, 9 Jul 2010 18:57:30 +1000 Subject: [py-dev] execnet wrt doing sysadmin work against a cluster of nodes Message-ID: Hi all, Would someone be able to show how execnet could be used to manage a cluster of nodes over ssh ? Just a simple example of executing a remote shell command (eg: uptime) against a cluster of nodes (host1, host2, host3). cheers James -- -- James Mills -- -- "Problems are solved by method" From memedough at gmail.com Fri Jul 9 12:47:53 2010 From: memedough at gmail.com (meme dough) Date: Fri, 9 Jul 2010 20:47:53 +1000 Subject: [py-dev] pytest-cov In-Reply-To: References: <20100708124022.GP14601@trillke.net> Message-ID: Hi, Invoke distributed testing with 2 test process both of which are on the same host but have different dirs: py.test --dist=each --tx=popen//chdir=/tmp/testarea1//python=/usr/bin/python2.5 --tx=popen//chdir=/tmp/testarea2//python=/usr/bin/python2.6 --rsyncdir=circuits The 2 test process are started by popen, and each one changes to it's respective dir. The /tmp/testarea1 & 2 get created. The circuits dir should be rsynced to the test areas. py.test will automatically send what it needs to work (py and xdist packages). Then you can see what happens in each test area. Look at what it rsyncs, does it send over the pyc files? Since each is separate then any generation of new pyc files should not conflict between the processes. This works for me but I'm not getting the same errors as you. :) On 9 July 2010 18:55, James Mills wrote: > On Fri, Jul 9, 2010 at 6:39 PM, meme dough wrote: >> Did you try deleting all .pyc and .pyo files in >> /home/prologic/work/circuits recursively and then trying? > > Yes, tried and same result. > >> Since it looks like python 2.6 will create the pyc files in the master >> process and then the popen to python 2.5 barfs on them. ?As Holger >> pointed out PYTHONDOWNWRITEBYTECODE should turn off the master python >> 2.6 creating pyc files. ?But if you've still got old ones lying around >> then the slave python 2.5 will no doubt barf. > > Also tried, same result. > >> Another solution to this maybe to give each test process it's own >> area. ?So change the working dir of each tx and specify the rsync >> option to get the proper code to each test area (I assume the rsync >> doesn't push pyc files). ?Also that way if your code relies on it's >> own resources in the dir tree (writing out to a log file for example) >> then they will be separate and not clash. > > Could you show an example tx config that does thsi ? > > cheers > James > > -- > -- James Mills > -- > -- "Problems are solved by method" > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > From memedough at gmail.com Sat Jul 10 17:14:25 2010 From: memedough at gmail.com (meme dough) Date: Sun, 11 Jul 2010 01:14:25 +1000 Subject: [py-dev] pytest-xdist limitations in interactions between different versions of python Message-ID: Hi Holger, I have a few questions for py.test with xdist and I'm not sure if these are known and I missed the something. When I kick off py.test with dist=each mode I've noticed 3 limitations in interactions between different versions of python. First if start py.test with python2.x then can specify any 2.x txes, so the following is fine: py.test --tb=short -r sfxX --dist=each --tx=popen//python=/usr/local/python246/bin/python --tx=popen//python=/usr/local/python255/bin/python --tx=popen//python=/usr/local/python265/bin/python However problems if txes for 3.0: py.test -v --tb=short -r sfxX --dist=each --tx=popen//python=/usr/local/python246/bin/python --tx=popen//python=/usr/local/python255/bin/python --tx=popen//python=/usr/local/python265/bin/python --tx=popen//python=/usr/local/python301/bin/python ========================= test session starts ========================= platform linux2 -- Python 2.6.4 -- pytest-1.3.2 -- /usr/bin/python test path 1: /home/memedough/work/projects/pytest-cov [gw0] popen//python=/usr/local/python246/bin/python -- platform linux2, Python 2.4.6-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python246/bin/python [gw1] popen//python=/usr/local/python255/bin/python -- platform linux2, Python 2.5.5-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python255/bin/python [gw2] popen//python=/usr/local/python265/bin/python -- platform linux2, Python 2.6.5-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python265/bin/python [gw3] popen//python=/usr/local/python301/bin/python -- platform linux2, Python 3.0.1-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python301/bin/python [master] starting full item collection ... [master] collected 7 items [gw0] txnode ready to receive tests [gw3] node down, error: [gw2] txnode ready to receive tests [gw1] txnode ready to receive tests Then I have to ctrl-c. Also problems if txes for 3.1: py.test -v --tb=short -r sfxX --dist=each --tx=popen//python=/usr/local/python246/bin/python --tx=popen//python=/usr/local/python255/bin/python --tx=popen//python=/usr/local/python265/bin/python --tx=popen//python=/usr/local/python312/bin/python ========================= test session starts ========================= platform linux2 -- Python 2.6.4 -- pytest-1.3.2 -- /usr/bin/python test path 1: /home/memedough/work/projects/pytest-cov [gw0] popen//python=/usr/local/python246/bin/python -- platform linux2, Python 2.4.6-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python246/bin/python [gw1] popen//python=/usr/local/python255/bin/python -- platform linux2, Python 2.5.5-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python255/bin/python [gw2] popen//python=/usr/local/python265/bin/python -- platform linux2, Python 2.6.5-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python265/bin/python [gw3] popen//python=/usr/local/python312/bin/python -- platform linux2, Python 3.1.2-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python312/bin/python [master] starting full item collection ... [master] collected 7 items [gw3] node down, error: ========================== in 1.79 seconds =========================== I didn't have to ctrl-c then, it varies I think. Second, if start py.test with python 3.0 then can specify 3.0 / 3.1, so the following is fine: py.test --tb=short -r sfxX --dist=each --tx=popen//python=/usr/local/python301/bin/python --tx=popen//python=/usr/local/python312/bin/python However problems if txes for 2.x: py.test -v --tb=short -r sfxX --dist=each --tx=popen//python=/usr/local/python301/bin/python --tx=popen//python=/usr/local/python265/bin/python =========================== test session starts =========================== platform linux2 -- Python 3.0.1 -- pytest-1.3.2 -- /usr/local/python301/bin/python test path 1: /home/memedough/work/projects/pytest-cov [gw0] popen//python=/usr/local/python301/bin/python -- platform linux2, Python 3.0.1-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python301/bin/python [gw1] popen//python=/usr/local/python265/bin/python -- platform linux2, Python 2.6.5-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python265/bin/python [master] starting full item collection ... [master] collected 7 items [gw1] node down, error: Traceback (most recent call last): File "/usr/local/python301/lib/python3.0/site-packages/execnet-1.0.7-py3.0.egg/execnet/gateway_base.py", line 725, in executetask do_exec(co, loc) File "", line 1, in do_exec File "", line 9, in File "/usr/local/python301/lib/python3.0/site-packages/pytest_xdist-1.4-py3.0.egg/xdist/mypickle.py", line 142, in receive return self._unpickle(pickled_obj) File "/usr/local/python301/lib/python3.0/site-packages/pytest_xdist-1.4-py3.0.egg/xdist/mypickle.py", line 147, in _unpickle return self._ipickle.loads(pickled_obj) File "/usr/local/python301/lib/python3.0/site-packages/pytest_xdist-1.4-py3.0.egg/xdist/mypickle.py", line 103, in loads res = unpickler.load() File "/usr/local/python265/lib/python2.6/pickle.py", line 858, in load dispatch[key](self) File "/usr/local/python265/lib/python2.6/pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "/usr/local/python265/lib/python2.6/pickle.py", line 1124, in find_class __import__(module) ImportError: No module named copyreg ============================ in 0.29 seconds ============================= Third, if start py.test with python 3.1 then can specify 3.1, so the following is fine: py.test --tb=short -r sfxX --dist=each --tx=popen//python=/usr/local/python312/bin/python --tx=popen//python=/usr/local/python312/bin/python However problems if txes for 3.0 or 2.x: py.test -v --tb=short -r sfxX --dist=each --tx=popen//python=/usr/local/python312/bin/python --tx=popen//python=/usr/local/python301/bin/python ========================== test session starts ========================== platform linux2 -- Python 3.1.2 -- pytest-1.3.2 -- /usr/local/python312/bin/python test path 1: /home/memedough/work/projects/pytest-cov [gw0] popen//python=/usr/local/python312/bin/python -- platform linux2, Python 3.1.2-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python312/bin/python [gw1] popen//python=/usr/local/python301/bin/python -- platform linux2, Python 3.0.1-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python301/bin/python [master] starting full item collection ... /usr/local/python312/lib/python3.1/site-packages/py-1.3.2-py3.1.egg/py/_test/pluginmanager.py:100: UserWarning: Module pytest_cov_init was already imported from /usr/local/python312/lib/python3.1/site-packages/pytest_cov-0.16a1-py3.1.egg/pytest_cov_init.py, but /home/memedough/work/projects/pytest-cov is being added to sys.path from pkg_resources import iter_entry_points [master] collected 7 items [gw1] node down, error: Traceback (most recent call last): File "/usr/local/python312/lib/python3.1/site-packages/execnet-1.0.7-py3.1.egg/execnet/gateway_base.py", line 725, in executetask do_exec(co, loc) File "", line 1, in do_exec File "", line 9, in File "/usr/local/python312/lib/python3.1/site-packages/pytest_xdist-1.4-py3.1.egg/xdist/mypickle.py", line 142, in receive return self._unpickle(pickled_obj) File "/usr/local/python312/lib/python3.1/site-packages/pytest_xdist-1.4-py3.1.egg/xdist/mypickle.py", line 147, in _unpickle return self._ipickle.loads(pickled_obj) File "/usr/local/python312/lib/python3.1/site-packages/pytest_xdist-1.4-py3.1.egg/xdist/mypickle.py", line 103, in loads res = unpickler.load() File "/usr/local/python301/lib/python3.0/pickle.py", line 813, in load dispatch[key[0]](self) File "/usr/local/python301/lib/python3.0/pickle.py", line 1058, in load_global klass = self.find_class(module, name) File "/usr/local/python301/lib/python3.0/pickle.py", line 1092, in find_class __import__(module, level=0) ImportError: No module named copy_reg =========================== in 0.34 seconds ============================ The 2.x problem is: py.test -v --tb=short -r sfxX --dist=each --tx=popen//python=/usr/local/python312/bin/python --tx=popen//python=/usr/local/python265/bin/python ========================== test session starts ========================== platform linux2 -- Python 3.1.2 -- pytest-1.3.2 -- /usr/local/python312/bin/python test path 1: /home/memedough/work/projects/pytest-cov [gw0] popen//python=/usr/local/python312/bin/python -- platform linux2, Python 3.1.2-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python312/bin/python [gw1] popen//python=/usr/local/python265/bin/python -- platform linux2, Python 2.6.5-final-0 cwd: /home/memedough/work/projects/pytest-cov- /usr/local/python265/bin/python [master] starting full item collection ... /usr/local/python312/lib/python3.1/site-packages/py-1.3.2-py3.1.egg/py/_test/pluginmanager.py:100: UserWarning: Module pytest_cov_init was already imported from /usr/local/python312/lib/python3.1/site-packages/pytest_cov-0.16a1-py3.1.egg/pytest_cov_init.py, but /home/memedough/work/projects/pytest-cov is being added to sys.path from pkg_resources import iter_entry_points [master] collected 7 items [gw0] txnode ready to receive tests [gw1] node down, error: pickled_obj = "(S'slaveready'\np162\n(t(dp164\ntp166\n." def unpickle_callback(pickled_obj): if pickled_obj is uniqueendmarker: return callback(endmarker) try: > obj = self._unpickle(pickled_obj) callback = > endmarker = -1 pickled_obj = "(S'slaveready'\np162\n(t(dp164\ntp166\n." self = uniqueendmarker = /usr/local/python312/lib/python3.1/site-packages/pytest_xdist-1.4-py3.1.egg/xdist/mypickle.py:173: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = pickled_obj = "(S'slaveready'\np162\n(t(dp164\ntp166\n." def _unpickle(self, pickled_obj): if isinstance(pickled_obj, self._channel.__class__): return pickled_obj > return self._ipickle.loads(pickled_obj) pickled_obj = "(S'slaveready'\np162\n(t(dp164\ntp166\n." self = /usr/local/python312/lib/python3.1/site-packages/pytest_xdist-1.4-py3.1.egg/xdist/mypickle.py:147: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = string = "(S'slaveready'\np162\n(t(dp164\ntp166\n." def loads(self, string): > f = py.io.BytesIO(string) E TypeError: 'str' does not support the buffer interface self = string = "(S'slaveready'\np162\n(t(dp164\ntp166\n." /usr/local/python312/lib/python3.1/site-packages/pytest_xdist-1.4-py3.1.egg/xdist/mypickle.py:100: TypeError I have to ctrl-c then. So: If 2.x then can have tx for 2.x but problems if tx for 3.x. If 3.0 then can have tx for 3.0 / 3.1 but problems if tx for 2.x. If 3.1 then can have tx for 3.1 but problems if tx for 2.x / 3.0. Do I have something wrong in my env or is it normal? :) From Ronny.Pfannschmidt at gmx.de Sat Jul 10 17:49:18 2010 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Sat, 10 Jul 2010 17:49:18 +0200 Subject: [py-dev] pytest-xdist limitations in interactions between different versions of python In-Reply-To: References: Message-ID: <1278776958.20320.2.camel@klappe2> Hi, as far as i know the interaction limitation is due to python3 breaking pickle interaction with python2 in the worst possible way. There are some plans to fix that by relying only on execnet serialization. I suppose Holger can tell more there. -- Ronny From memedough at gmail.com Sun Jul 11 08:40:35 2010 From: memedough at gmail.com (meme dough) Date: Sun, 11 Jul 2010 16:40:35 +1000 Subject: [py-dev] pytest-cov new cmd line options, reports, sub process support (not released though) Message-ID: Hi, I've been looking at reworking pytest-cov a bit. The cmd line options are just down to 3 with .coveragerc file used to control rest. For dist=each mode just combine and do one report since people indicate that's desirable. Also added collecting sub process coverage as well. Provided that env vars make it to the sub process then it's coverage will get measured. It also works straight out of the box. It uses the up coming coverage 3.4 which has new api to specify source roots so it won't be released until after coverage released, but I'm not in hurry myself. In case anyone is interested you can try out the 1.0a1 with something like this to get sandbox area to play with: cd /tmp virtualenv --distribute --no-site-packages e1 source e1/bin/activate wget http://bitbucket.org/memedough/coverage.py/get/1a09065be67b.tar.gz tar xvzf 1a09065be67b.tar.gz cd coverage.py python setup.py install cd /tmp wget http://bitbucket.org/memedough/pytest-cov/get/9cc5f8c43fd8.tar.gz tar xvzf 9cc5f8c43fd8.tar.gz cd pytest-cov python setup.py install Note that I have a temp fork of coverage just to fix it's own pytest plugin that causes pytest to crash. So I will delete that once upstream fixed. :) From holger at merlinux.eu Sun Jul 11 12:32:00 2010 From: holger at merlinux.eu (holger krekel) Date: Sun, 11 Jul 2010 12:32:00 +0200 Subject: [py-dev] execnet wrt doing sysadmin work against a cluster of nodes In-Reply-To: References: Message-ID: <20100711103200.GS14601@trillke.net> Hi James, here is an example of obtaining system information from hosts: http://bitbucket.org/hpk42/execnet/src/tip/doc/example/sysinfo.py When I use it like this: python sysinfo.py codespeak.net speed.pypy.org tannit i get something like this: connecting to 'ssh=codespeak.net' CODESPEAK.NET fqdn: codespeak.net CODESPEAK.NET sys.platform: linux2 CODESPEAK.NET sys.version_info: (2, 4, 2, 'final', 0) CODESPEAK.NET Memory: 904720 Swap: 1023992 CODESPEAK.NET number of cpus: 1 CODESPEAK.NET cpu model QEMU Virtual CPU version 0.11.0 connecting to 'ssh=speed.pypy.org' SPEED.PYPY.ORG fqdn: testrun.org SPEED.PYPY.ORG sys.platform: linux2 SPEED.PYPY.ORG sys.version_info: (2, 6, 2, 'final', 0) SPEED.PYPY.ORG Memory: 1011512 Swap: 1023992 SPEED.PYPY.ORG number of cpus: 1 SPEED.PYPY.ORG cpu model QEMU Virtual CPU version 0.11.0 connecting to 'ssh=tannit' TANNIT fqdn: tannit.openend.se TANNIT sys.platform: linux2 TANNIT sys.version_info: (2, 6, 4, 'final', 0) TANNIT Memory: 12322012 Swap: 12693496 TANNIT number of cpus: 4 TANNIT cpu model Intel(R) Xeon(R) CPU W3580 @ 3.33GHz cheers, holger From holger at merlinux.eu Sun Jul 11 13:35:14 2010 From: holger at merlinux.eu (holger krekel) Date: Sun, 11 Jul 2010 13:35:14 +0200 Subject: [py-dev] pytest-xdist limitations in interactions between different versions of python In-Reply-To: <1278776958.20320.2.camel@klappe2> References: <1278776958.20320.2.camel@klappe2> Message-ID: <20100711113514.GU14601@trillke.net> On Sat, Jul 10, 2010 at 17:49 +0200, Ronny Pfannschmidt wrote: > as far as i know the interaction limitation is due to python3 breaking > pickle interaction with python2 in the worst possible way. > > > There are some plans to fix that by relying only on execnet > serialization. > > I suppose Holger can tell more there. The basic idea is indeed to try to get rid of using Pickle for transfering information between the test master and slave processes. This can happen on the "application" level, i.e. modifying and adding custom serialization for py.test related objects or by extending the serializaer to allow basic pickling of instances in some limited way. best, holger From holger at merlinux.eu Sun Jul 11 14:46:38 2010 From: holger at merlinux.eu (holger krekel) Date: Sun, 11 Jul 2010 14:46:38 +0200 Subject: [py-dev] pytest-cov new cmd line options, reports, sub process support (not released though) In-Reply-To: References: Message-ID: <20100711124638.GW14601@trillke.net> Hi Meme, thanks for the great write up! Eager to try it out :) do you think it makes sense to disable coverage's own py.test - plugin? cheers, holger On Sun, Jul 11, 2010 at 16:40 +1000, meme dough wrote: > I've been looking at reworking pytest-cov a bit. > > The cmd line options are just down to 3 with .coveragerc file used to > control rest. > > For dist=each mode just combine and do one report since people > indicate that's desirable. > > Also added collecting sub process coverage as well. Provided that env > vars make it to the sub process then it's coverage will get measured. > It also works straight out of the box. > > It uses the up coming coverage 3.4 which has new api to specify source > roots so it won't be released until after coverage released, but I'm > not in hurry myself. > > In case anyone is interested you can try out the 1.0a1 with something > like this to get sandbox area to play with: > > cd /tmp > virtualenv --distribute --no-site-packages e1 > source e1/bin/activate > wget http://bitbucket.org/memedough/coverage.py/get/1a09065be67b.tar.gz > tar xvzf 1a09065be67b.tar.gz > cd coverage.py > python setup.py install > cd /tmp > wget http://bitbucket.org/memedough/pytest-cov/get/9cc5f8c43fd8.tar.gz > tar xvzf 9cc5f8c43fd8.tar.gz > cd pytest-cov > python setup.py install > > Note that I have a temp fork of coverage just to fix it's own pytest > plugin that causes pytest to crash. So I will delete that once > upstream fixed. > > :) > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From memedough at gmail.com Sun Jul 11 15:11:51 2010 From: memedough at gmail.com (meme dough) Date: Sun, 11 Jul 2010 23:11:51 +1000 Subject: [py-dev] pytest-cov new cmd line options, reports, sub process support (not released though) In-Reply-To: <20100711124638.GW14601@trillke.net> References: <20100711124638.GW14601@trillke.net> Message-ID: Hi, How would disable the coverage plugin? It has setuptools entry point, disable in coverage? Or pytest? Or patch coverage source? The big problem atm is just that it got out of sync with other code so pytest crashed since it's trying to get cover_actions which didn't exist. It has a lot of help output atm but indications they will be cut down. pytest-coverage probably need update to diff prefix maybe --coverage, last time i checked it was hidden by coverage plugin. :) On 11 July 2010 22:46, holger krekel wrote: > Hi Meme, > > thanks for the great write up! > Eager to try it out :) > > do you think it makes sense to disable coverage's own py.test - plugin? > > cheers, > holger > > On Sun, Jul 11, 2010 at 16:40 +1000, meme dough wrote: >> I've been looking at reworking pytest-cov a bit. >> >> The cmd line options are just down to 3 with .coveragerc file used to >> control rest. >> >> For dist=each mode just combine and do one report since people >> indicate that's desirable. >> >> Also added collecting sub process coverage as well. ?Provided that env >> vars make it to the sub process then it's coverage will get measured. >> It also works straight out of the box. >> >> It uses the up coming coverage 3.4 which has new api to specify source >> roots so it won't be released until after coverage released, but I'm >> not in hurry myself. >> >> In case anyone is interested you can try out the 1.0a1 with something >> like this to get sandbox area to play with: >> >> cd /tmp >> virtualenv --distribute --no-site-packages e1 >> source e1/bin/activate >> wget http://bitbucket.org/memedough/coverage.py/get/1a09065be67b.tar.gz >> tar xvzf 1a09065be67b.tar.gz >> cd coverage.py >> python setup.py install >> cd /tmp >> wget http://bitbucket.org/memedough/pytest-cov/get/9cc5f8c43fd8.tar.gz >> tar xvzf 9cc5f8c43fd8.tar.gz >> cd pytest-cov >> python setup.py install >> >> Note that I have a temp fork of coverage just to fix it's own pytest >> plugin that causes pytest to crash. ?So I will delete that once >> upstream fixed. >> >> :) >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev >> > > -- > From holger at merlinux.eu Sun Jul 11 15:35:31 2010 From: holger at merlinux.eu (holger krekel) Date: Sun, 11 Jul 2010 15:35:31 +0200 Subject: [py-dev] pytest-cov new cmd line options, reports, sub process support (not released though) In-Reply-To: References: <20100711124638.GW14601@trillke.net> Message-ID: <20100711133531.GX14601@trillke.net> On Sun, Jul 11, 2010 at 23:11 +1000, meme dough wrote: > Hi, > > How would disable the coverage plugin? It has setuptools entry point, > disable in coverage? Or pytest? Or patch coverage source? By telling Ned to not include it / disable it. This way we/you are more free to advance things without depending on coverage releases. Eventually i'd like to be able to point people to a single approach for using coverage with py.test. If i understand it correctly, James and you are both working with pytest-cov now, right? best, holger > The big problem atm is just that it got out of sync with other code so > pytest crashed since it's trying to get cover_actions which didn't > exist. > > It has a lot of help output atm but indications they will be cut down. > > pytest-coverage probably need update to diff prefix maybe --coverage, > last time i checked it was hidden by coverage plugin. > > :) > > On 11 July 2010 22:46, holger krekel wrote: > > Hi Meme, > > > > thanks for the great write up! > > Eager to try it out :) > > > > do you think it makes sense to disable coverage's own py.test - plugin? > > > > cheers, > > holger > > > > On Sun, Jul 11, 2010 at 16:40 +1000, meme dough wrote: > >> I've been looking at reworking pytest-cov a bit. > >> > >> The cmd line options are just down to 3 with .coveragerc file used to > >> control rest. > >> > >> For dist=each mode just combine and do one report since people > >> indicate that's desirable. > >> > >> Also added collecting sub process coverage as well. ?Provided that env > >> vars make it to the sub process then it's coverage will get measured. > >> It also works straight out of the box. > >> > >> It uses the up coming coverage 3.4 which has new api to specify source > >> roots so it won't be released until after coverage released, but I'm > >> not in hurry myself. > >> > >> In case anyone is interested you can try out the 1.0a1 with something > >> like this to get sandbox area to play with: > >> > >> cd /tmp > >> virtualenv --distribute --no-site-packages e1 > >> source e1/bin/activate > >> wget http://bitbucket.org/memedough/coverage.py/get/1a09065be67b.tar.gz > >> tar xvzf 1a09065be67b.tar.gz > >> cd coverage.py > >> python setup.py install > >> cd /tmp > >> wget http://bitbucket.org/memedough/pytest-cov/get/9cc5f8c43fd8.tar.gz > >> tar xvzf 9cc5f8c43fd8.tar.gz > >> cd pytest-cov > >> python setup.py install > >> > >> Note that I have a temp fork of coverage just to fix it's own pytest > >> plugin that causes pytest to crash. ?So I will delete that once > >> upstream fixed. > >> > >> :) > >> _______________________________________________ > >> py-dev mailing list > >> py-dev at codespeak.net > >> http://codespeak.net/mailman/listinfo/py-dev > >> > > > > -- > > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From jaraco at jaraco.com Sun Jul 11 18:13:09 2010 From: jaraco at jaraco.com (Jason R. Coombs) Date: Sun, 11 Jul 2010 09:13:09 -0700 Subject: [py-dev] Using py.test with setuptools Message-ID: <12C7AB425F0DD546B6049311F827C74E08A2D4E36B@VA3DIAXVS141.RED001.local> I see that setuptools has an interface for launching the tests via 'setup.py test': http://peak.telecommunity.com/DevCenter/setuptools#test-loader I see that the tests work with nose and unittest. Does py.test provide the necessary interfaces to launch py.test via setuptools? I've confirmed my tests are running naturally; I run 'py.test' and the tests run and pass. I tried passing test_suite='py.test' to the setup command, and this does indeed launch py.test from 'setup.py test', but no tests are run. I tried specifying the collector class 'py.test.collect.Collector' and cmdline 'py.test.cmdline.main', but neither of these options worked (as they don't supply the expected interfaces). Any suggestions for using py.test from setuptools? Thanks, Jason From Ronny.Pfannschmidt at gmx.de Sun Jul 11 18:39:34 2010 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Sun, 11 Jul 2010 18:39:34 +0200 Subject: [py-dev] Using py.test with setuptools In-Reply-To: <12C7AB425F0DD546B6049311F827C74E08A2D4E36B@VA3DIAXVS141.RED001.local> References: <12C7AB425F0DD546B6049311F827C74E08A2D4E36B@VA3DIAXVS141.RED001.local> Message-ID: <1278866374.4286.6.camel@klappe2> On Sun, 2010-07-11 at 09:13 -0700, Jason R. Coombs wrote: > I see that setuptools has an interface for launching the tests via 'setup.py test': http://peak.telecommunity.com/DevCenter/setuptools#test-loader > > I see that the tests work with nose and unittest. Does py.test provide the necessary interfaces to launch py.test via setuptools? > > I've confirmed my tests are running naturally; I run 'py.test' and the tests run and pass. I tried passing test_suite='py.test' to the setup command, and this does indeed launch py.test from 'setup.py test', but no tests are run. I tried specifying the collector class 'py.test.collect.Collector' and cmdline 'py.test.cmdline.main', but neither of these options worked (as they don't supply the expected interfaces). > > Any suggestions for using py.test from setuptools? > It wont work that way, py.test is not based on the unittest interfaces, thats the only thing setuptools supports. The execnet package has code that shows how this could work, by supplying a new test command class instead. Take a look if http://bitbucket.org/hpk42/execnet/src/tip/setup.py#cl-67 might fiy your needs. Maybe this should be extended and included in py.test or tox. -- Ronny From holger at merlinux.eu Mon Jul 12 13:31:37 2010 From: holger at merlinux.eu (holger krekel) Date: Mon, 12 Jul 2010 13:31:37 +0200 Subject: [py-dev] tox, a new generic virtualenv/test management tool Message-ID: <20100712113136.GA14601@trillke.net> I have been talking about it with various people lately and am now happy announce the first release of "tox". tox aims to automate tedious Python related test activities driven from a simple ``tox.ini`` file, including: * creation and management of virtualenv environments * installing your Python package into each of them * run your test tool of choice (nose, py.test, unittests, you name it) * testing packages against each other without needing to upload to PyPI tox runs well on Python2.4 up until Python3.1 and integrates well with Continous Integration servers like Hudson. There are many real-life examples and a fair amount of docs. Read up on http://codespeak.net/tox and please report any issues. This is a fresh project and i'd like to drive further improvements from real world needs and feedback. thanks & cheers, holger krekel From holger at merlinux.eu Mon Jul 12 15:39:11 2010 From: holger at merlinux.eu (holger krekel) Date: Mon, 12 Jul 2010 15:39:11 +0200 Subject: [py-dev] tox, a new generic virtualenv/test management tool In-Reply-To: <20100712113136.GA14601@trillke.net> References: <20100712113136.GA14601@trillke.net> Message-ID: <20100712133911.GC14601@trillke.net> note: it might be that there are crucial issues with tox-0.5 on OSX - Michael reported one which i am investigating. It could break your environment so please use things with care on OSX for now. holger On Mon, Jul 12, 2010 at 13:31 +0200, holger krekel wrote: > > I have been talking about it with various people lately and > am now happy announce the first release of "tox". > > tox aims to automate tedious Python related test activities driven > from a simple ``tox.ini`` file, including: > > * creation and management of virtualenv environments > * installing your Python package into each of them > * run your test tool of choice (nose, py.test, unittests, you name it) > * testing packages against each other without needing to upload to PyPI > > tox runs well on Python2.4 up until Python3.1 and integrates > well with Continous Integration servers like Hudson. There are many > real-life examples and a fair amount of docs. Read up on > > http://codespeak.net/tox > > and please report any issues. This is a fresh project and > i'd like to drive further improvements from real world needs > and feedback. > > thanks & cheers, > holger krekel > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From holger at merlinux.eu Mon Jul 12 20:29:10 2010 From: holger at merlinux.eu (holger krekel) Date: Mon, 12 Jul 2010 20:29:10 +0200 Subject: [py-dev] tox-0.6: virtualenv-creation fixes on OSX In-Reply-To: <20100712113136.GA14601@trillke.net> References: <20100712113136.GA14601@trillke.net> Message-ID: <20100712182910.GD14601@trillke.net> Hi all, thanks to Michael Foord's help i just released a tox-0.6 to PYPI which should fix some crucial issues wrt to virtualenv creation on OSX. best, holger On Mon, Jul 12, 2010 at 13:31 +0200, holger krekel wrote: > I have been talking about it with various people lately and > am now happy announce the first release of "tox". > > tox aims to automate tedious Python related test activities driven > from a simple ``tox.ini`` file, including: > > * creation and management of virtualenv environments > * installing your Python package into each of them > * run your test tool of choice (nose, py.test, unittests, you name it) > * testing packages against each other without needing to upload to PyPI > > tox runs well on Python2.4 up until Python3.1 and integrates > well with Continous Integration servers like Hudson. There are many > real-life examples and a fair amount of docs. Read up on > > http://codespeak.net/tox > > and please report any issues. This is a fresh project and > i'd like to drive further improvements from real world needs > and feedback. > > thanks & cheers, > holger krekel > > _______________________________________________ > testing-in-python mailing list > testing-in-python at lists.idyll.org > http://lists.idyll.org/listinfo/testing-in-python > -- From holger at merlinux.eu Tue Jul 13 12:05:19 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 13 Jul 2010 12:05:19 +0200 Subject: [py-dev] renaming py and py.test, worth it? Message-ID: <20100713100519.GJ14601@trillke.net> Hi all, every now and then i am thinking about a renaming strategy for the py lib. Main reasons why i want to rename: * "py" is too generic a name * i want to separate py.test and py packages (py.path and other non-py.test bits are used by quite some projects and it makes no sense to enforce installation of py.test scripts) Here is the strategy: (1) rename py to XXlib (XX being any two letters) (2) rename py.test to AAtest (AA being any two letters) (3) provide a script that helps to replace occurences of "import py" etc. (4) maintain and release XXlib and AAtest separately (5) provide a compatibility "py" package that depends on XXlib and AAtest The (4) is actually slightly tricky because with the rename to AAtest the "pytest_*" hooks should be renamed as well. I can imagine to discover both "pytest_" and "AAtest_" hooks for the first releases after the split. Although i'd aim to minimize the pain this split would certainly cause some. What do you think? Worth it? best, holger From issues-noreply at bitbucket.org Tue Jul 13 14:08:20 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Tue, 13 Jul 2010 12:08:20 -0000 Subject: [py-dev] New issue 110 in py-trunk: Unicode filenames are not correctly supported Message-ID: <05fd290e42ac0ba0a12ca0174363b91b@bitbucket.org> --- you can reply above this line --- New issue 110: Unicode filenames are not correctly supported http://bitbucket.org/hpk42/py-trunk/issue/110/unicode-filenames-are-not-correctly amauryfa on Tue, 13 Jul 2010 14:08:20 +0200: Description: Given the following file structure: {{{ rootdir/subdir/unicode???.txt }}} py.svnwcrevert will fail on Windows, it executes commands like this: {{{ >>> py.path.local('rootdir').remove(rec=1) Traceback (most recent call last): File "", line 1, in File "D:\afa\pypy\trunk1\py\_path\local.py", line 166, in remove self.chmod(448, rec=1) # octcal 0700 File "D:\afa\pypy\trunk1\py\_path\local.py", line 494, in chmod py.error.checked_call(os.chmod, str(x), mode) File "D:\afa\pypy\trunk1\py\_error.py", line 80, in checked_call raise cls("%s%r" % (func.__name__, args)) py.error.ENOTDIR: [Not a directory]: chmod('D:\\rootdir\\subdir\\unicode???.txt', 448) }}} This causes the pypy buildbot to fail, because the @temp files are not correctly cleaned before a run. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From sridharr at activestate.com Tue Jul 13 17:16:52 2010 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Tue, 13 Jul 2010 08:16:52 -0700 Subject: [py-dev] renaming py and py.test, worth it? In-Reply-To: <20100713100519.GJ14601@trillke.net> References: <20100713100519.GJ14601@trillke.net> Message-ID: <4C3C8364.4040602@activestate.com> I won't mind at this. But as a forewarning it may be a good idea to first provide DeprecationWarning in the next few releases before doing a rename. Something like: "DeprecationWarning: The `py.test` package is being deprecated; starting from release 1.5.0 it will be renamed to `xxtest`. Please visit http://xxtest.org/migration-from-py.test.html for details on migration" -srid On 7/13/2010 3:05 AM, holger krekel wrote: > Hi all, > > every now and then i am thinking about a renaming strategy for > the py lib. Main reasons why i want to rename: > > * "py" is too generic a name > * i want to separate py.test and py packages (py.path and other > non-py.test bits are used by quite some projects and it makes > no sense to enforce installation of py.test scripts) > > Here is the strategy: > > (1) rename py to XXlib (XX being any two letters) > (2) rename py.test to AAtest (AA being any two letters) > (3) provide a script that helps to replace occurences of "import py" etc. > (4) maintain and release XXlib and AAtest separately > (5) provide a compatibility "py" package that depends on XXlib and AAtest > > The (4) is actually slightly tricky because with the rename to AAtest > the "pytest_*" hooks should be renamed as well. I can imagine to > discover both "pytest_" and "AAtest_" hooks for the first releases > after the split. > > Although i'd aim to minimize the pain this split would certainly cause some. > > What do you think? > Worth it? > > best, > holger > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev From holger at merlinux.eu Tue Jul 13 20:14:56 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 13 Jul 2010 20:14:56 +0200 Subject: [py-dev] renaming py and py.test, worth it? In-Reply-To: <4C3C8364.4040602@activestate.com> References: <20100713100519.GJ14601@trillke.net> <4C3C8364.4040602@activestate.com> Message-ID: <20100713181456.GN14601@trillke.net> Hi Sridhar, On Tue, Jul 13, 2010 at 08:16 -0700, Sridhar Ratnakumar wrote: > I won't mind at this. But as a forewarning it may be a good idea to > first provide DeprecationWarning in the next few releases before doing a > rename. Something like: > > "DeprecationWarning: The `py.test` package is being deprecated; > starting from release 1.5.0 it will be renamed to `xxtest`. Please visit > http://xxtest.org/migration-from-py.test.html for details on migration" Yes, that could be part of the py-1.4 compat package (which would depend on and use the XXlib and AAtest packages). best, holger > > -srid > > On 7/13/2010 3:05 AM, holger krekel wrote: >> Hi all, >> >> every now and then i am thinking about a renaming strategy for >> the py lib. Main reasons why i want to rename: >> >> * "py" is too generic a name >> * i want to separate py.test and py packages (py.path and other >> non-py.test bits are used by quite some projects and it makes >> no sense to enforce installation of py.test scripts) >> >> Here is the strategy: >> >> (1) rename py to XXlib (XX being any two letters) >> (2) rename py.test to AAtest (AA being any two letters) >> (3) provide a script that helps to replace occurences of "import py" etc. >> (4) maintain and release XXlib and AAtest separately >> (5) provide a compatibility "py" package that depends on XXlib and AAtest >> >> The (4) is actually slightly tricky because with the rename to AAtest >> the "pytest_*" hooks should be renamed as well. I can imagine to >> discover both "pytest_" and "AAtest_" hooks for the first releases >> after the split. >> >> Although i'd aim to minimize the pain this split would certainly cause some. >> >> What do you think? >> Worth it? >> >> best, >> holger >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev > -- From fdg001 at gmx.net Wed Jul 14 08:59:00 2010 From: fdg001 at gmx.net (Frederik Dohr) Date: Wed, 14 Jul 2010 07:59:00 +0100 Subject: [py-dev] renaming py and py.test, worth it? In-Reply-To: <20100713181456.GN14601@trillke.net> References: <20100713100519.GJ14601@trillke.net> <4C3C8364.4040602@activestate.com> <20100713181456.GN14601@trillke.net> Message-ID: <4C3D6034.9050501@gmx.net> > I won't mind at this. Ditto - it might be a bit of a hassle for users, but shouldn't be too painful by the sound of it. > provide DeprecationWarning in the next few releases before doing a rename Would the current package disappear from PyPI eventually? I imagine it's possible that someone returns to maintain a package after a few years of inactivity - if py.test was nowhere to be found then, it might be quite discouraging. (Perhaps that concern is excessive, but worth considering at least.) -- F. From holger at merlinux.eu Wed Jul 14 10:29:38 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 14 Jul 2010 10:29:38 +0200 Subject: [py-dev] renaming py and py.test, worth it? In-Reply-To: <4C3D6034.9050501@gmx.net> References: <20100713100519.GJ14601@trillke.net> <4C3C8364.4040602@activestate.com> <20100713181456.GN14601@trillke.net> <4C3D6034.9050501@gmx.net> Message-ID: <20100714082938.GO14601@trillke.net> Hi Frederik, Sridhar, all, On Wed, Jul 14, 2010 at 07:59 +0100, Frederik Dohr wrote: > > I won't mind at this. > > Ditto - it might be a bit of a hassle for users, but shouldn't be too > painful by the sound of it. It does affect lots of already written code so it has a cost. > > provide DeprecationWarning in the next few releases before doing a rename > > Would the current package disappear from PyPI eventually? I imagine it's > possible that someone returns to maintain a package after a few years of > inactivity - if py.test was nowhere to be found then, it might be quite > discouraging. (Perhaps that concern is excessive, but worth considering > at least.) valid concern. I think the "py" package would remain at PYPI but depend and strongly point to the other ones. best, holger From holger at merlinux.eu Wed Jul 14 10:46:02 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 14 Jul 2010 10:46:02 +0200 Subject: [py-dev] maybe just a split, no rename (was: renaming py and py.test) In-Reply-To: <20100713100519.GJ14601@trillke.net> References: <20100713100519.GJ14601@trillke.net> Message-ID: <20100714084602.GP14601@trillke.net> hi all, so apart from the feedback here i talked to Ronny, James and Thomas on IRC and it seems to me not one person welcomes a complete rename. Rather i consider now just going for a split py -> pylib, pytest and maybe also "pytools" (the py.cleanup etc. helpers). Somehow the packages would need to share the "py." namespace, probably not too difficult. No test or pylib-depending code would need to change and there could be a compatibility "py" package that depends on pylib/pytest/pytools. Would be mostly work for me and packaging/distribution maintainers, i guess. best, holger On Tue, Jul 13, 2010 at 12:05 +0200, holger krekel wrote: > Hi all, > > every now and then i am thinking about a renaming strategy for > the py lib. Main reasons why i want to rename: > > * "py" is too generic a name > * i want to separate py.test and py packages (py.path and other > non-py.test bits are used by quite some projects and it makes > no sense to enforce installation of py.test scripts) > > Here is the strategy: > > (1) rename py to XXlib (XX being any two letters) > (2) rename py.test to AAtest (AA being any two letters) > (3) provide a script that helps to replace occurences of "import py" etc. > (4) maintain and release XXlib and AAtest separately > (5) provide a compatibility "py" package that depends on XXlib and AAtest > > The (4) is actually slightly tricky because with the rename to AAtest > the "pytest_*" hooks should be renamed as well. I can imagine to > discover both "pytest_" and "AAtest_" hooks for the first releases > after the split. > > Although i'd aim to minimize the pain this split would certainly cause some. > > What do you think? > Worth it? > > best, > holger > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From holger at merlinux.eu Wed Jul 14 22:58:04 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 14 Jul 2010 22:58:04 +0200 Subject: [py-dev] tox-0.7: fixes, python3-compat, site-packages Message-ID: <20100714205804.GT14601@trillke.net> Hi all, thanks to feedback and help from Michael Foord, Sridhar Ratnakumar, Kumar McMillan, Ronny Pfannschmidt and Ralf Schmitt i just released tox-0.7 which includes a couple of fixes, improved Python3 virtualenv support (on non-windows platforms), and a new sitepackages config option that let's you use globally installed packages. See the more detailed changelog below. The web page is here: http://codespeak.net/tox have fun, holger What is Tox? ---------------- TOX as is a virtualenv management and generic test command line tool you can use for: * checking your package installs correctly with different Python versions and interpreters * running your tests in each of the environments, configuring your test tool of choice * acting as a frontend to Continous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing. Changes 0.7 ---------------------- - use virtualenv5 (my own fork of virtualenv3) for now to create python3 environments, fixes a couple of issues and makes tox more likely to work with Python3 (on non-windows environments) - add ``sitepackages`` option for testenv sections so that environments can be created with access to globals (default is not to have access, i.e. create environments with ``--no-site-packages``. - addressing issue4: always prepend venv-path to PATH variable when calling subprocesses - fix issue2: exit with proper non-zero return code if there were errors or test failures. - added unittest2 examples contributed by Michael Foord - only allow 'True' or 'False' for boolean config values (lowercase / uppercase is irrelevant) - recreate virtualenv on changed configurations 0.6 ----------------- - fix OSX related bugs that could cause the caller's environment to get screwed (sorry). tox was using the same file as virtualenv for tracking the Python executable dependency and there also was confusion wrt links. this should be fixed now. - fix long description, thanks Michael Foord 0.5 ----------------- - initial release From issues-noreply at bitbucket.org Sun Jul 18 21:16:34 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sun, 18 Jul 2010 19:16:34 -0000 Subject: [py-dev] New issue 111 in py-trunk: py.test installation instructions bad for windows machines Message-ID: <9165a7472ca878c983e4c52369d5c0f3@bitbucket.org> --- you can reply above this line --- New issue 111: py.test installation instructions bad for windows machines http://bitbucket.org/hpk42/py-trunk/issue/111/pytest-installation-instructions-bad-for-windows Anonymous on Sun, 18 Jul 2010 21:16:34 +0200: Description: I am referring to these: http://codespeak.net/py/dist/install.html When installing py.test, the main python installation adirectory and Scripts subdir (e.g. "C:\Python2.6\" and "C:\Python2.6\Scripts") must be added to the windows path. This issue is only mentioned in the "troubleshooting" section, which points here: "http://docs.python.org/faq/windows#how-do-i-run-a-python-program-under-windows". However, this link does not mention the need to add the \Scripts directory, so it really does not help the user at all. On a side note, I think the installation guide is too complicated. Anything that requires more than zero thought and 30 seconds is deterring users who are "shopping" for testing frameworks. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Tue Jul 20 09:59:55 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Tue, 20 Jul 2010 07:59:55 -0000 Subject: [py-dev] New issue 112 in py-trunk: A way to report failures as soon as they occur, not afterwards Message-ID: --- you can reply above this line --- New issue 112: A way to report failures as soon as they occur, not afterwards http://bitbucket.org/hpk42/py-trunk/issue/112/a-way-to-report-failures-as-soon-as-they-occur-not Anonymous on Tue, 20 Jul 2010 09:59:55 +0200: Description: Now all tests are run and failures reported afterwards, so for a huge test suite, you can't start fixing the first failures, nor you know that this is a critical failure and just stop the test run. It would be nice if you could pass some parameter and get reports interleaved with test runs. It's not the same as "stop on first failure", because tests should keep on running even after reporting a failed test. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Fri Jul 23 18:04:41 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Fri, 23 Jul 2010 16:04:41 -0000 Subject: [py-dev] New issue 113 in py-trunk: SyntaxError when an assert fails and a triple-quoted string spans lines Message-ID: <66327780e5a884afc0f0c53bee2839ce@bitbucket.org> --- you can reply above this line --- New issue 113: SyntaxError when an assert fails and a triple-quoted string spans lines http://bitbucket.org/hpk42/py-trunk/issue/113/syntaxerror-when-an-assert-fails-and-a-triple-quoted-string-spans Anonymous on Fri, 23 Jul 2010 18:04:40 +0200: Description: {{{ #!python def test_break_pytest(): """ py.test gives "SyntaxError: EOF while scanning triple-quoted string literal" when an assert fails and a triple-quoted string spans lines NB. this does not occur when the the assert succeeds """ assert "" == """ """ }}} -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From memedough at gmail.com Thu Jul 29 10:33:31 2010 From: memedough at gmail.com (meme dough) Date: Thu, 29 Jul 2010 18:33:31 +1000 Subject: [py-dev] Separate pytest_generate_tests for separate test functions? Message-ID: Hi, I was wondering about the pytest_generate_tests which can make many parameterise test from 1 test function. When I have many tests and I want to parameterise a number of them the pytest_generate_tests function has to have a if metafunc.function == xxx elif metafunc.function == yyy etc. This means a big switch statement on which function it is. It also means that parameterised data for a function may be a long way from it. This can happen easy when have a test module per source module. Are there any ideas maybe for a pytest_generate_tests for each function that needs to be parameterised? Maybe like pytest_generate_tests__myfunc(metafunc) which can create many tests for the test_myfunc ? Just curious if this would be a good idea or not. :) From holger at merlinux.eu Thu Jul 29 10:49:49 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 29 Jul 2010 10:49:49 +0200 Subject: [py-dev] Separate pytest_generate_tests for separate test functions? In-Reply-To: References: Message-ID: <20100729084949.GA1914@trillke.net> Hi Meme, On Thu, Jul 29, 2010 at 18:33 +1000, meme dough wrote: > Hi, > > I was wondering about the pytest_generate_tests which can make many > parameterise test from 1 test function. > > When I have many tests and I want to parameterise a number of them the > pytest_generate_tests function has to have a if metafunc.function == > xxx elif metafunc.function == yyy etc. > > This means a big switch statement on which function it is. It also > means that parameterised data for a function may be a long way from > it. This can happen easy when have a test module per source module. > > Are there any ideas maybe for a pytest_generate_tests for each > function that needs to be parameterised? Maybe like > pytest_generate_tests__myfunc(metafunc) which can create many tests > for the test_myfunc ? > > Just curious if this would be a good idea or not. > > :) The parametrized testing mechanism is quite low level. As exemplified in http://tetamap.wordpress.com/2009/05/13/ there are various ways to build higher-level parametrized testing. You can e.g. write a generic pytest_generate_tests that invokes a decorator of a test function (or some attribute on its test class) thus allowing very specified and close-to-the-test parametrization. Note: currently pytest_generate_tests cannot easily be combined, i.e. if you have test_func(arg1, arg2) you cannot have two independent pytest_generate_tests method which generate values for each of the args. See also the ISSUES.txt in the repo where there are some notes about parametrized testing. best, holger From holger at merlinux.eu Thu Jul 29 13:04:25 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 29 Jul 2010 13:04:25 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <4C24E72F.3080802@gmx.de> References: <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> <20100625100535.GI14601@trillke.net> <4C248D7E.70104@gmx.de> <20100625141908.GJ14601@trillke.net> <4C24D321.7090804@gmx.de> <20100625171115.GN14601@trillke.net> <4C24E72F.3080802@gmx.de> Message-ID: <20100729110425.GC1914@trillke.net> Hi Frank, The issue109 is from you, i think. See http://bitbucket.org/hpk42/py-trunk/issue/109/implicit-loading-of-sibling-directorys I realize you are subscribed "Anonymous" to the issue so you probably didn't see my question: where is the patch? best, holger On Fri, Jun 25, 2010 at 19:28 +0200, Frank Hempel wrote: > Am 25.06.2010 19:11, schrieb holger krekel: > > On Fri, Jun 25, 2010 at 18:02 +0200, Frank Hempel wrote: > >> Am 25.06.2010 16:19, schrieb holger krekel: > > > > Somewhat although i consider it bad practise to do sys.path manipulations > > in pytest_configure. It probably also means that you can get trouble when > > you run things from the root dir and both the 'a' and 'b' tests are run. > > I agree with your opinion. I just could not get something more stupid > into mind... ;) > > > Anyway, i agree it'd be nicer if py.test would not implicitely load the > > sibling directory's conftest.py. Could you care to file an "enhancement" > > issue in the bitbucket tracker? If you add a test case that you'd like to > > work that'd be good. I am not sure i fix it for the soon upcoming minor > > release but i definitely give it a try for 1.4. > > I will do that. Thank's for your agreement :) > > Best Regards, > Frank > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From red_socks at gmx.de Fri Jul 30 12:10:55 2010 From: red_socks at gmx.de (Frank Hempel) Date: Fri, 30 Jul 2010 12:10:55 +0200 Subject: [py-dev] funcarg name clash / conftest load behaviour In-Reply-To: <20100729110425.GC1914@trillke.net> References: <20100624144057.GD14601@trillke.net> <4C246640.8030508@gmx.de> <20100625085503.GG14601@trillke.net> <4C247A72.3060903@gmx.de> <20100625100535.GI14601@trillke.net> <4C248D7E.70104@gmx.de> <20100625141908.GJ14601@trillke.net> <4C24D321.7090804@gmx.de> <20100625171115.GN14601@trillke.net> <4C24E72F.3080802@gmx.de> <20100729110425.GC1914@trillke.net> Message-ID: <4C52A52F.9080503@gmx.de> Am 29.07.2010 13:04, schrieb holger krekel: > Hi Frank, > > The issue109 is from you, i think. See > > http://bitbucket.org/hpk42/py-trunk/issue/109/implicit-loading-of-sibling-directorys > > I realize you are subscribed "Anonymous" to the issue so you probably > didn't see my question: where is the patch? Back then I posted it as anonymous comment. Meanwhile I managed it to register at bitbucket :) so I attached the reviewed patch as a file. Thanks, Best regards, Frank From phil at freehackers.org Fri Jul 30 16:40:54 2010 From: phil at freehackers.org (Philippe Fremy) Date: Fri, 30 Jul 2010 16:40:54 +0200 Subject: [py-dev] unittest2 plugin system for python stdlib Message-ID: <4C52E476.7070100@freehackers.org> Hi Holger, I don't know if you are following python-dev, but in case not, you definitely need to have a look at this: http://mail.python.org/pipermail/python-dev/2010-July/102526.html http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186 To quote: "As part of the prototype I have been implementing some example plugins (in unittest2/plugins/) so I can develop the mechanism against real rather than imagined use cases. Jason Pellerin, creator of nose, has been providing me with feedback and has been trying it out by porting some of the nose plugins to unittest [1]. His initial comment on the system was "it looks very flexible and clean". ;-)" I am sure that your feedback would be very valuable too, given the extrem pluginness of py.test . cheers, Philippe From holger at merlinux.eu Fri Jul 30 23:52:13 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 30 Jul 2010 23:52:13 +0200 Subject: [py-dev] unittest2 plugin system for python stdlib In-Reply-To: <4C52E476.7070100@freehackers.org> References: <4C52E476.7070100@freehackers.org> Message-ID: <20100730215212.GF1914@trillke.net> Hi Philippe, (CC Michael (who can post as well)), thanks for the pointer! Michael and me discussed plugin system ideas on several occassions, last at EuroPython2010 a week ago. I tried to give early feedback and he actually ported two py.test plugins. I haven't looked at his recent work and somewhat long-ish emails, though. I guess i am going to let the dust settle a bit, maybe steal back some ideas and aim at more testing tool convergence (which was one topic of my discussions with Michael and Jason at some point). best, holger On Fri, Jul 30, 2010 at 16:40 +0200, Philippe Fremy wrote: > > Hi Holger, > > I don't know if you are following python-dev, but in case not, you > definitely need to have a look at this: > > http://mail.python.org/pipermail/python-dev/2010-July/102526.html > http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186 > > To quote: > "As part of the prototype I have been implementing some example plugins > (in unittest2/plugins/) so I can develop the mechanism against real > rather than imagined use cases. Jason Pellerin, creator of nose, has > been providing me with feedback and has been trying it out by porting > some of the nose plugins to unittest [1]. His initial comment on the > system was "it looks very flexible and clean". ;-)" > > I am sure that your feedback would be very valuable too, given the > extrem pluginness of py.test . > > cheers, > > Philippe > > > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From fuzzyman at voidspace.org.uk Fri Jul 30 23:54:32 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 30 Jul 2010 22:54:32 +0100 Subject: [py-dev] unittest2 plugin system for python stdlib In-Reply-To: <20100730215212.GF1914@trillke.net> References: <4C52E476.7070100@freehackers.org> <20100730215212.GF1914@trillke.net> Message-ID: <4C534A18.3080807@voidspace.org.uk> On 30/07/2010 22:52, holger krekel wrote: > Hi Philippe, (CC Michael (who can post as well)), > > thanks for the pointer! Michael and me discussed plugin system ideas > on several occassions, last at EuroPython2010 a week ago. I tried to give > early feedback and he actually ported two py.test plugins. I haven't looked at > his recent work and somewhat long-ish emails, though. I guess i am going to let > the dust settle a bit, maybe steal back some ideas and aim at more testing tool > convergence (which was one topic of my discussions with Michael and Jason at > some point). > > Hey guys, Sorry Holger - I forgot to mention all the help you had been to me in my early formulation of the system. You mainly gave me ideas and inspiration though, none of the actual system is your fault. :-) Michael > best, > holger > > On Fri, Jul 30, 2010 at 16:40 +0200, Philippe Fremy wrote: > >> Hi Holger, >> >> I don't know if you are following python-dev, but in case not, you >> definitely need to have a look at this: >> >> http://mail.python.org/pipermail/python-dev/2010-July/102526.html >> http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186 >> >> To quote: >> "As part of the prototype I have been implementing some example plugins >> (in unittest2/plugins/) so I can develop the mechanism against real >> rather than imagined use cases. Jason Pellerin, creator of nose, has >> been providing me with feedback and has been trying it out by porting >> some of the nose plugins to unittest [1]. His initial comment on the >> system was "it looks very flexible and clean". ;-)" >> >> I am sure that your feedback would be very valuable too, given the >> extrem pluginness of py.test . >> >> cheers, >> >> Philippe >> >> >> >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev >> >> > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. From holger at merlinux.eu Sat Jul 31 00:41:25 2010 From: holger at merlinux.eu (holger krekel) Date: Sat, 31 Jul 2010 00:41:25 +0200 Subject: [py-dev] distributed testing fixes (execnet-1.0.8 and a green experiment) Message-ID: <20100730224125.GI1914@trillke.net> hi all, see below for one and a half execnet releases which fix some issues that were originally registered as py.test ones, namely rsync issues with symbolic links and permissions. You can do "pip -U execnet" or "pip -U pytest-xdist" to make sure you have the latest of everything. ("easy_install" is fine as well). best, holger ----- Forwarded message from holger krekel ----- Date: Sat, 31 Jul 2010 00:34:04 +0200 From: holger krekel To: execnet-dev at codespeak.net, python announce User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Subject: [execnet-dev] execnet-1.0.8 and a green experiment I just released execnet-1.0.8, see the Changelog for details, below. What is execnet? --------------------- execnet is a small pure python library that manages distributed code execution across Python versions and host boundaries. It provides a self-bootstrapping share-nothing model with channels to send/receive data messages. It also helps with managing a cluster of (local or remote) processes and comes with tons of examples and API docs: http://codespeak.net/execnet green version of execnet -------------------------------- For those interested i hacked up a green version of execnet which is API-compatible (and less stable) than the "main" version which relies on operating system threads. The green version requires the eventlet library and is thus not fully self-bootstrapping (you need to install eventlet on all remote nodes you want to execute code on). There is no release but you can peruse http://code.google.com/p/execnet-green/source/checkout and "python setup.py develop" to play with it. It will never spawn any operating system threads. Rather remote_exec() will spawn greenlets/micro-threads of which you can easily have a few thousand. It probably only is stable enough for simple scenarios at this point. best, holger Changelog 1.0.8 (compared to 1.0.7): - new ``gateway.remote_exec(func, **kwargs)`` style fo executing a pure function with parameters. The function on the remote side also needs to accept a ``channel`` which allows it to communicate back and forth. Thanks to Ronny Pfannschmidt for implementing it with special kudos to Maciej Fijalkowski for writing a "pure-function" checker so that on Python2.6 onwards non-pure functions will be rejected. - enhance rsyncing to also sync permissions (stat().st_mode) of directories and files. (should also resolve http://bitbucket.org/hpk42/py-trunk/issue/68/) - fix rsyncing of symlinks, thanks to Charles Solar (should also resolve http://bitbucket.org/hpk42/py-trunk/issue/70/) - update internal usage of apipkg to 1.0b6 - remote_exec(module) now makes sure that the linecache is updated before reading and sending the source. thanks Ronny, Matt. - removed all trailing whitespace from source files _______________________________________________ execnet-dev mailing list execnet-dev at codespeak.net http://codespeak.net/mailman/listinfo/execnet-dev ----- End forwarded message ----- -- From holger at merlinux.eu Sat Jul 31 02:22:04 2010 From: holger at merlinux.eu (holger krekel) Date: Sat, 31 Jul 2010 02:22:04 +0200 Subject: [py-dev] tox-0.8 and py.test-1.3.3 released Message-ID: <20100731002204.GJ1914@trillke.net> Hi, just did a two test tool releases, one for tox and one for py.test. The tox-0.8 release provides fixes and workarounds, see changelog below. The py-1.3.3 release mainly provides fixes for terminal output. best & thanks to the respective feedbackers/helpers, holger What is tox? ---------------------- Tox is a generic test runner, creating virtualenv environments on the fly and executing your test tool of choice. It works conveniently from a developer's terminal as well as from a Continous Integration Server. See http://codespeak.net/tox What is py.test? ---------------------- py.test is an easy-to-learn testing tool with many plugins and features for integration and functional tests in Python. See http://pytest.org for more info. CHANGES tox-0.8 ----------------- - work around a virtualenv limitation which crashes if PYTHONDONTWRITEBYTECODE is set. - run pip/easy installs from the environment log directory, avoids naming clashes between env names and dependencies (thanks ronny) - require a more recent version of py lib - refactor and refine config detection to work from a single file and to detect the case where a python installation overwrote an old one and resulted in a new executable. This invalidates the existing virtualenvironment now. - change all internal source to strip trailing whitespaces Changes py-1.3.3 ---------------------- - fix issue113: assertion representation problem with triple-quoted strings (and possibly other cases) - make conftest loading detect that a conftest file with the same content was already loaded, avoids surprises in nested directory structures which can be produced e.g. by Hudson. It probably removes the need to use --confcutdir in most cases. - fix terminal coloring for win32 (thanks Michael Foord for reporting) - fix weirdness: make terminal width detection work on stdout instead of stdin (thanks Armin Ronacher for reporting) - remove trailing whitespace in all py/text distribution files From memedough at gmail.com Mon Aug 2 15:45:10 2010 From: memedough at gmail.com (meme dough) Date: Mon, 2 Aug 2010 23:45:10 +1000 Subject: [py-dev] pytest-cov Message-ID: Hi, I decided not to wait for coverage source option to be released. I will release again when it is available. pytest-cov now has slimmer command line interface which is pleasant when doing py.test -h It should measure sub processes out of the box (provided I got the pth file installed in the correct location, works with what I have available for testing). It will do the sub processes for distributed testing too. I will be putting it through it's paces in more depth. A doc update on the site would probably be good. Give it a try if anyone interested and let me know how it goes. :) From holger at merlinux.eu Mon Aug 2 16:05:43 2010 From: holger at merlinux.eu (holger krekel) Date: Mon, 2 Aug 2010 16:05:43 +0200 Subject: [py-dev] pytest-cov In-Reply-To: References: Message-ID: <20100802140543.GP1914@trillke.net> Hi Meme, On Mon, Aug 02, 2010 at 23:45 +1000, meme dough wrote: > Hi, > > I decided not to wait for coverage source option to be released. I > will release again when it is available. good idea :) > pytest-cov now has slimmer command line interface which is pleasant > when doing py.test -h very nice! > It should measure sub processes out of the box (provided I got the pth > file installed in the correct location, works with what I have > available for testing). It will do the sub processes for distributed > testing too. Hum, how does the "out-of-the-box" work exactly? It won't always be enabled just because pytest-cov is installed, will it? (if so, i'd rather suggest to do an indirection and only perform coverage if a certain environment varialbe like PYTEST_COV_AUTOSUB=1 or so it st). > I will be putting it through it's paces in more depth. > > A doc update on the site would probably be good. > > Give it a try if anyone interested and let me know how it goes. I tried it, worked fine (and i really like the slim interface!). Notes: * --cov=path ... the help string should say what path, file-system or python import-path? * when i ran "py.test --cov=py._code" it worked fine, i.e. only showed results for the py._code subpackage. When i mistype the path, e.g. "py.test --cov=py._code2" it will give me *all* results which is wrong: i'd expect "no coverage data for import path "py._code2" found or something like this. cheers, holger From holger at merlinux.eu Tue Aug 3 10:14:28 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 3 Aug 2010 10:14:28 +0200 Subject: [py-dev] pytest-cov In-Reply-To: <20100802140543.GP1914@trillke.net> References: <20100802140543.GP1914@trillke.net> Message-ID: <20100803081428.GQ1914@trillke.net> On Mon, Aug 02, 2010 at 16:05 +0200, holger krekel wrote: > Hum, how does the "out-of-the-box" work exactly? > It won't always be enabled just because pytest-cov is installed, will it? > (if so, i'd rather suggest to do an indirection and only perform coverage > if a certain environment varialbe like PYTEST_COV_AUTOSUB=1 or so it st). FYI i think pytest-cov begins to work better than pytest-figleaf in some cases! :) However, i consider it crucial that installing pytest-cov has no side effects by default. With the above suggestion we could make py.test set the environment variable when a coverage-run is selected and otherwise avoid any side effects, particularly when py.test is not even run. IOW, i'd be very happy with a pytest-cov-1.1 streamlining this issue so it's safe to point people to it :) best, holger > > > I will be putting it through it's paces in more depth. > > > > A doc update on the site would probably be good. > > > > Give it a try if anyone interested and let me know how it goes. > > I tried it, worked fine (and i really like the slim interface!). > Notes: > > * --cov=path ... the help string should say what path, file-system or > python import-path? > > * when i ran "py.test --cov=py._code" it worked fine, i.e. only showed > results for the py._code subpackage. When i mistype the path, > e.g. "py.test --cov=py._code2" it will give me *all* results which > is wrong: i'd expect "no coverage data for import path "py._code2" found > or something like this. > > cheers, > holger > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From memedough at gmail.com Tue Aug 3 13:57:21 2010 From: memedough at gmail.com (meme dough) Date: Tue, 3 Aug 2010 21:57:21 +1000 Subject: [py-dev] pytest-cov In-Reply-To: <20100803081428.GQ1914@trillke.net> References: <20100802140543.GP1914@trillke.net> <20100803081428.GQ1914@trillke.net> Message-ID: Hi, On 3 August 2010 18:14, holger krekel wrote: > On Mon, Aug 02, 2010 at 16:05 +0200, holger krekel wrote: >> Hum, how does the "out-of-the-box" work exactly? >> It won't always be enabled just because pytest-cov is installed, will it? >> (if so, i'd rather suggest to do an indirection and only perform coverage >> if a certain environment varialbe like PYTEST_COV_AUTOSUB=1 or so it st). > > FYI i think pytest-cov begins to work better than pytest-figleaf > in some cases! :) > > However, i consider it crucial that installing pytest-cov has no side effects > by default. ?With the above suggestion we could make py.test set the environment > variable when a coverage-run is selected and otherwise avoid any side effects, > particularly when py.test is not even run. ?IOW, i'd be very happy with a > pytest-cov-1.1 streamlining this issue so it's safe to point people to it :) When pytest-cov installed (well really cov-core) an init_cov_core.pth will be created. During python site initialisation this will cause coverage to start only if appropriate. From the doc string: Activate coverage at python startup if appropriate. The python site initialisation will ensure that anything we import will be removed and not visible at the end of python startup. However we minimise all work by putting these init actions in this separate module and only importing what is needed when needed. For normal python startup when coverage should not be activated we only import os, look for one env var and get out. For python startup when an ancestor process has set the env indicating that code coverage is being collected we activate coverage based on info passed via env vars. So I completely agree with you. One issue is creating the pth file during installation. It works for me with what I have to test with. If it can't find site-packages / dist-packages then it outputs a message describing what file to create and content to go in it. Another issue is uninstalling. I added a big note indicating that the pth file must be uninstalled manually. >> * --cov=path ... the help string should say what path, file-system or >> ? python import-path? I was tying to be consistent with other pytest options and path looked the best as used by others. Under hood it is currently morf (modules or files coverage speak) but will change to source option which is a root of a source tree so I think path is the good like following. Suggestions? --junitxml=path --ignore=path --genscript=path >> * when i ran "py.test --cov=py._code" it worked fine, i.e. only showed >> ? results for the py._code subpackage. ?When i mistype the path, >> ? e.g. "py.test --cov=py._code2" it will give me *all* results which >> ? is wrong: i'd expect "no coverage data for import path "py._code2" found >> ? or something like this. If all --cov options don't give something valid then everything collected is dumped (and everything was collect unless you use omit option in config file and omit is changing a lot with new source / include / omit). This is where source option comes in. With source option specify the roots of trees then limited to those roots since measurement itself is not done outside of those trees. :) From holger at merlinux.eu Tue Aug 3 14:17:00 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 3 Aug 2010 14:17:00 +0200 Subject: [py-dev] pytest-cov In-Reply-To: References: <20100802140543.GP1914@trillke.net> <20100803081428.GQ1914@trillke.net> Message-ID: <20100803121700.GR1914@trillke.net> Hi Meme, On Tue, Aug 03, 2010 at 21:57 +1000, meme dough wrote: > On 3 August 2010 18:14, holger krekel wrote: > > On Mon, Aug 02, 2010 at 16:05 +0200, holger krekel wrote: > >> Hum, how does the "out-of-the-box" work exactly? > >> It won't always be enabled just because pytest-cov is installed, will it? > >> (if so, i'd rather suggest to do an indirection and only perform coverage > >> if a certain environment varialbe like PYTEST_COV_AUTOSUB=1 or so it st). > > > > FYI i think pytest-cov begins to work better than pytest-figleaf > > in some cases! :) > > > > However, i consider it crucial that installing pytest-cov has no side effects > > by default. ?With the above suggestion we could make py.test set the environment > > variable when a coverage-run is selected and otherwise avoid any side effects, > > particularly when py.test is not even run. ?IOW, i'd be very happy with a > > pytest-cov-1.1 streamlining this issue so it's safe to point people to it :) > > When pytest-cov installed (well really cov-core) an init_cov_core.pth > will be created. During python site initialisation this will cause > coverage to start only if appropriate. From the doc string: > > Activate coverage at python startup if appropriate. > > The python site initialisation will ensure that anything we import > will be removed and not visible at the end of python startup. However > we minimise all work by putting these init actions in this separate > module and only importing what is needed when needed. > > For normal python startup when coverage should not be activated we > only import os, look for one env var and get out. > > For python startup when an ancestor process has set the env indicating > that code coverage is being collected we activate coverage based on > info passed via env vars. If i understand correctly you are describing the situation as is. Sorry, i didn't look at the content of cov_core_init.py which would have revealed the mechanics that you describe. > So I completely agree with you. > > One issue is creating the pth file during installation. It works for > me with what I have to test with. If it can't find site-packages / > dist-packages then it outputs a message describing what file to create > and content to go in it. > > Another issue is uninstalling. I added a big note indicating that the > pth file must be uninstalled manually. I guess somehow "pip" should be better able to uninstall. But ok, cov_core_init.py is hopefully not causing trouble so it's not so bad. > >> * --cov=path ... the help string should say what path, file-system or > >> ? python import-path? > > I was tying to be consistent with other pytest options and path looked > the best as used by others. Under hood it is currently morf (modules > or files coverage speak) but will change to source option which is a > root of a source tree so I think path is the good like following. > Suggestions? > > --junitxml=path > --ignore=path > --genscript=path these are all file system paths. > >> * when i ran "py.test --cov=py._code" it worked fine, i.e. only showed > >> ? results for the py._code subpackage. ?When i mistype the path, > >> ? e.g. "py.test --cov=py._code2" it will give me *all* results which > >> ? is wrong: i'd expect "no coverage data for import path "py._code2" found > >> ? or something like this. > > If all --cov options don't give something valid then everything > collected is dumped (and everything was collect unless you use omit > option in config file and omit is changing a lot with new source / > include / omit). This remains then the only issue i guess: rather give information that the specified "--cov=XYZ" restriction was used and turn up *no* results (even if coverage defaults disagree). Seeing everything is almost never what wants to see if "--cov=MORF" was specified. Do you agree and see a way to implement this within pytest-cov? Another minor note: when using --cov-report=html no information is printed at all. Like the junitxml or figleaf plugin i suggest to print the location of the generated html directory or directly the index.html file. best & thanks for your nice work! holger > This is where source option comes in. With source option specify the > roots of trees then limited to those roots since measurement itself is > not done outside of those trees. > > :) > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From memedough at gmail.com Tue Aug 3 14:43:30 2010 From: memedough at gmail.com (meme dough) Date: Tue, 3 Aug 2010 22:43:30 +1000 Subject: [py-dev] pytest-cov In-Reply-To: <20100803121700.GR1914@trillke.net> References: <20100802140543.GP1914@trillke.net> <20100803081428.GQ1914@trillke.net> <20100803121700.GR1914@trillke.net> Message-ID: Hi, > If i understand correctly you are describing the situation as is. > Sorry, i didn't look at the content of cov_core_init.py which would > have revealed the mechanics that you describe. Yes, that's how it is now. Not expecting you to dig into the code - just easier for me to paste it in rather than type it again :) > I guess somehow "pip" should be better able to uninstall. ?But ok, > cov_core_init.py is hopefully not causing trouble so it's not so bad. python setup.py install (have to manually remove) easy_install (have to manually remove) pip (if distutils / distutils2 / setuptools / distribute / pip could install and uninstall a pth file that would be great but I haven't seen way yet) >> --junitxml=path >> --ignore=path >> --genscript=path > > these are all file system paths. That is what it will be, but I can look at clarify it now. > This remains then the only issue i guess: rather give information > that the specified "--cov=XYZ" restriction was used and turn up > *no* results (even if coverage defaults disagree). ?Seeing everything > is almost never what wants to see if "--cov=MORF" was specified. > Do you agree and see a way to implement this within pytest-cov? That's interesting, I hadn't thought of it. Should be able to do it though I will look. > Another minor note: when using --cov-report=html no information > is printed at all. ?Like the junitxml or figleaf plugin i suggest > to print the location of the generated html directory or directly > the index.html file. That output could be useful and won't hurt if under continuous integration. I will look to see if possible to get the file path easily (could always get from config file or default but if can get from coverage better). :) From holger at merlinux.eu Tue Aug 3 15:01:27 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 3 Aug 2010 15:01:27 +0200 Subject: [py-dev] pytest-cov In-Reply-To: References: <20100802140543.GP1914@trillke.net> <20100803081428.GQ1914@trillke.net> <20100803121700.GR1914@trillke.net> Message-ID: <20100803130127.GS1914@trillke.net> On Tue, Aug 03, 2010 at 22:43 +1000, meme dough wrote: > Hi, > > > If i understand correctly you are describing the situation as is. > > Sorry, i didn't look at the content of cov_core_init.py which would > > have revealed the mechanics that you describe. > > Yes, that's how it is now. Not expecting you to dig into the code - > just easier for me to paste it in rather than type it again :) > > > I guess somehow "pip" should be better able to uninstall. ?But ok, > > cov_core_init.py is hopefully not causing trouble so it's not so bad. > > python setup.py install (have to manually remove) > easy_install (have to manually remove) > pip (if distutils / distutils2 / setuptools / distribute / pip could > install and uninstall a pth file that would be great but I haven't > seen way yet) Maybe you can change the IMPORTANT note to mention that the "cov-core" package is installing this init_cov_core.pth file so that people do not unneccessarily suspect the innocent pytest-cov plugin :) > >> --junitxml=path > >> --ignore=path > >> --genscript=path > > > > these are all file system paths. > > That is what it will be, but I can look at clarify it now. great. maybe just adapt the help string to "measure coverage for fs/import path (multi-allowed)" or so. > > This remains then the only issue i guess: rather give information > > that the specified "--cov=XYZ" restriction was used and turn up > > *no* results (even if coverage defaults disagree). ?Seeing everything > > is almost never what wants to see if "--cov=MORF" was specified. > > Do you agree and see a way to implement this within pytest-cov? > > That's interesting, I hadn't thought of it. Should be able to do it > though I will look. > > > Another minor note: when using --cov-report=html no information > > is printed at all. ?Like the junitxml or figleaf plugin i suggest > > to print the location of the generated html directory or directly > > the index.html file. > > That output could be useful and won't hurt if under continuous > integration. I will look to see if possible to get the file path > easily (could always get from config file or default but if can get > from coverage better). I think there even is some standard coverage reporting format that e.g. Hudson can read. Or it can at least grab the generated HTML. Never looked into it but would probably would be cool to have such reports available with CI runs :) best, holger From holger at merlinux.eu Wed Aug 4 12:39:08 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 4 Aug 2010 12:39:08 +0200 Subject: [py-dev] pytest-cov measuring multiple subprocesses? (+notes) Message-ID: <20100804103908.GT1914@trillke.net> Hi Meme, i am using pytest-cov for a project where I start multiple subprocesses. I am wondering how to best do this, here is the scenario: def test_functional(): popen1 = subprocess.Popen(...) # new python process popen2 = subprocess.Popen(...) # new python process popen1.terminate() popen2.wait() and now i want pytest-cov to show me the coverage. What do i need to do? Should it "just" work with this: py.test --cov=mypkg ? An unrelated note: the py.test distributed coverage-reporting feature ("DistMaster" etc.) is living with cov_core.py IISIC. Is this actually re-usable from nosetests? If not it would probably make more sense to have this code in pytest-cov for it to be easier to modify and maintain, no? another unrelated note: i like plugins to not cause import overhead if their functionality is not actually used. What about importing cov_core only when coverage is actually active? :) best, holger From memedough at gmail.com Thu Aug 5 12:51:42 2010 From: memedough at gmail.com (meme dough) Date: Thu, 5 Aug 2010 20:51:42 +1000 Subject: [py-dev] pytest-cov measuring multiple subprocesses? (+notes) In-Reply-To: <20100804103908.GT1914@trillke.net> References: <20100804103908.GT1914@trillke.net> Message-ID: Hi, > i am using pytest-cov for a project where I start multiple subprocesses. > I am wondering how to best do this, here is the scenario: > > ? ?def test_functional(): > ? ? ? ?popen1 = subprocess.Popen(...) # new python process > ? ? ? ?popen2 = subprocess.Popen(...) # new python process > ? ? ? ?popen1.terminate() > ? ? ? ?popen2.wait() > > > and now i want pytest-cov to show me the coverage. > What do i need to do? ?Should it "just" work with this: > > ? ?py.test --cov=mypkg > > ? Yes, it should just work provided that the subprocesses are python (as you state above) that have pytest-cov / cov-core installed. Only other thing is that it site initialisation as normal and env inherited as normal. Those sub processes detect env var and start coverage. Sub processes finish and write coverage file (specific per process), then master py.test finish and combine and report. > An unrelated note: the py.test distributed coverage-reporting feature > ("DistMaster" etc.) is living with cov_core.py IISIC. Is this actually re-usable > from nosetests? ?If not it would probably make more sense to have this code in > pytest-cov for it to be easier to modify and maintain, no? I liked having all the cov controllers together, but it is possible to move. > another unrelated note: i like plugins to not cause import overhead if > their functionality is not actually used. ?What about importing cov_core > only when coverage is actually active? > :) Yes this is good way. :) From jaraco at jaraco.com Thu Aug 5 17:05:49 2010 From: jaraco at jaraco.com (Jason R. Coombs) Date: Thu, 5 Aug 2010 08:05:49 -0700 Subject: [py-dev] feedback on py.test discovery/setup/process documentation Message-ID: <12C7AB425F0DD546B6049311F827C74E08A5FCE427@VA3DIAXVS141.RED001.local> I was espousing the joys of py.test at a recent #DCPython meetup. I found, however, that I'm not the only person frustrated by the lack of documentation on the basic process py.test uses to discover, setup, and conduct tests. There's mention here and there of setup/teardown methods, and their names are fairly intuitive, but I can't find that they're documented anywhere. It would be nice if there was a half-page document on the process py.test uses to conduct a single test. something like: # globally Run pytest_configure For each test module matching test_*.py: Run setup_module(module object) For each class in module.Test*: skip if it's not a valid test class (i.e. has an __init__ method) Run setup_class(class_object) [p.s. why doesn't setup_class have to be a classmethod?] For each method: Run setup_method(instance, method) Run test Run teardown_method Run teardown_class . I've discovered all of this through trial and error (and tracking down examples here and there). For example, I couldn't find setup_method documented anywhere, even though I knew what I wanted (a setup for each test to be run). Also, it would be nice to have some clarification on which classes will be discovered. I was recently bitten by an interesting feature. If a test class has an __init__ method, it will not be run as a test. For one test, I was using the __init__ method to define setup for each instance of the test. It turns out that by using setup_method instead of __init__, it did precisely what I wanted, but I went several weeks thinking my tests were running, when they were being silently skipped. I realize that all of this seems a little nitpicky. Truly, I love py.test, but I have to agree with my colleagues that it's a little difficult getting to know the basics. It doesn't help matters that because of the name, it's difficult to search the web for py.test resources. If you have any suggestions on how I might have learned these details other than through trial-and-error, please point me to them. Regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20100805/186450b0/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6448 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20100805/186450b0/attachment.bin From holger at merlinux.eu Thu Aug 5 17:28:55 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 5 Aug 2010 17:28:55 +0200 Subject: [py-dev] feedback on py.test discovery/setup/process documentation In-Reply-To: <12C7AB425F0DD546B6049311F827C74E08A5FCE427@VA3DIAXVS141.RED001.local> References: <12C7AB425F0DD546B6049311F827C74E08A5FCE427@VA3DIAXVS141.RED001.local> Message-ID: <20100805152854.GU1914@trillke.net> Hi Jason, thanks for the feedback, i appreciate it. I am aware that documentation needs some love - i actually plan to port it to sphinx (which has builtin search apart from other nicities) and add an example section. That being said, under http://codespeak.net/py/dist/test/features.html there is a link to "xUnit style setup": http://codespeak.net/py/dist/test/xunit_setup.html which may help a bit regarding the hooks. It doesn't mention pytest_configure which is mentioned here: http://codespeak.net/py/dist/test/customize.html ... so i guess it's true that things should be organised more according to usage patterns / needs rather than the structure of the implementation. Oh, and feel free to write blog posts about things you found so we can link them :) best, holger On Thu, Aug 05, 2010 at 08:05 -0700, Jason R. Coombs wrote: > I was espousing the joys of py.test at a recent #DCPython meetup. I found, > however, that I'm not the only person frustrated by the lack of > documentation on the basic process py.test uses to discover, setup, and > conduct tests. > > > > There's mention here and there of setup/teardown methods, and their names > are fairly intuitive, but I can't find that they're documented anywhere. It > would be nice if there was a half-page document on the process py.test uses > to conduct a single test. something like: > > > > # globally > > Run pytest_configure > > For each test module matching test_*.py: > > Run setup_module(module object) > > For each class in module.Test*: > > skip if it's not a valid test class (i.e. > has an __init__ method) > > Run setup_class(class_object) [p.s. why > doesn't setup_class have to be a classmethod?] > > For each method: > > Run setup_method(instance, > method) > > Run test > > Run teardown_method > > Run teardown_class > > . > > > > I've discovered all of this through trial and error (and tracking down > examples here and there). For example, I couldn't find setup_method > documented anywhere, even though I knew what I wanted (a setup for each test > to be run). > > > > Also, it would be nice to have some clarification on which classes will be > discovered. I was recently bitten by an interesting feature. If a test class > has an __init__ method, it will not be run as a test. For one test, I was > using the __init__ method to define setup for each instance of the test. It > turns out that by using setup_method instead of __init__, it did precisely > what I wanted, but I went several weeks thinking my tests were running, when > they were being silently skipped. > > > > I realize that all of this seems a little nitpicky. Truly, I love py.test, > but I have to agree with my colleagues that it's a little difficult getting > to know the basics. It doesn't help matters that because of the name, it's > difficult to search the web for py.test resources. > > > > If you have any suggestions on how I might have learned these details other > than through trial-and-error, please point me to them. > > > > Regards, > > > > Jason > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev -- From jaraco at jaraco.com Thu Aug 5 22:46:24 2010 From: jaraco at jaraco.com (Jason R. Coombs) Date: Thu, 5 Aug 2010 13:46:24 -0700 Subject: [py-dev] feedback on py.test discovery/setup/process documentation In-Reply-To: <20100805152854.GU1914@trillke.net> References: <12C7AB425F0DD546B6049311F827C74E08A5FCE427@VA3DIAXVS141.RED001.local> <20100805152854.GU1914@trillke.net> Message-ID: <12C7AB425F0DD546B6049311F827C74E08A60DC9D8@VA3DIAXVS141.RED001.local> That's a big help. I had bypassed the xUnit docs because the name sounded like a feature in which I wasn't interested (just because of the name). Silly me. Thanks for the reference. > -----Original Message----- > From: holger krekel [mailto:holger at merlinux.eu] > Sent: Thursday, 05 August, 2010 11:29 > To: Jason R. Coombs > Cc: py-dev at codespeak.net > Subject: Re: [py-dev] feedback on py.test discovery/setup/process > documentation > > Hi Jason, > > thanks for the feedback, i appreciate it. I am aware that documentation > needs some love - i actually plan to port it to sphinx (which has builtin search > apart from other nicities) and add an example section. > > That being said, under > > http://codespeak.net/py/dist/test/features.html > > there is a link to "xUnit style setup": > > http://codespeak.net/py/dist/test/xunit_setup.html > > which may help a bit regarding the hooks. It doesn't mention > pytest_configure which is mentioned here: > > http://codespeak.net/py/dist/test/customize.html > > ... so i guess it's true that things should be organised more according to usage > patterns / needs rather than the structure of the implementation. Oh, and > feel free to write blog posts about things you found so we can link them :) > > best, > holger > > On Thu, Aug 05, 2010 at 08:05 -0700, Jason R. Coombs wrote: > > I was espousing the joys of py.test at a recent #DCPython meetup. I > > found, however, that I'm not the only person frustrated by the lack of > > documentation on the basic process py.test uses to discover, setup, > > and conduct tests. > > > > > > > > There's mention here and there of setup/teardown methods, and their > > names are fairly intuitive, but I can't find that they're documented > > anywhere. It would be nice if there was a half-page document on the > > process py.test uses to conduct a single test. something like: > > > > > > > > # globally > > > > Run pytest_configure > > > > For each test module matching test_*.py: > > > > Run setup_module(module object) > > > > For each class in module.Test*: > > > > skip if it's not a valid test class (i.e. > > has an __init__ method) > > > > Run setup_class(class_object) [p.s. > > why doesn't setup_class have to be a classmethod?] > > > > For each method: > > > > Run > > setup_method(instance, > > method) > > > > Run test > > > > Run teardown_method > > > > Run teardown_class > > > > . > > > > > > > > I've discovered all of this through trial and error (and tracking down > > examples here and there). For example, I couldn't find setup_method > > documented anywhere, even though I knew what I wanted (a setup for > > each test to be run). > > > > > > > > Also, it would be nice to have some clarification on which classes > > will be discovered. I was recently bitten by an interesting feature. > > If a test class has an __init__ method, it will not be run as a test. > > For one test, I was using the __init__ method to define setup for each > > instance of the test. It turns out that by using setup_method instead > > of __init__, it did precisely what I wanted, but I went several weeks > > thinking my tests were running, when they were being silently skipped. > > > > > > > > I realize that all of this seems a little nitpicky. Truly, I love > > py.test, but I have to agree with my colleagues that it's a little > > difficult getting to know the basics. It doesn't help matters that > > because of the name, it's difficult to search the web for py.test resources. > > > > > > > > If you have any suggestions on how I might have learned these details > > other than through trial-and-error, please point me to them. > > > > > > > > Regards, > > > > > > > > Jason > > > > > > > _______________________________________________ > > py-dev mailing list > > py-dev at codespeak.net > > http://codespeak.net/mailman/listinfo/py-dev > > > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6448 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20100805/dafaf8c5/attachment-0001.bin From sridharr at activestate.com Thu Aug 5 22:46:14 2010 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Thu, 05 Aug 2010 13:46:14 -0700 Subject: [py-dev] py.test api - Running tests in a module object? Message-ID: <4C5B2316.7050909@activestate.com> I am trying to run py.test on a given module object dynamically. mod = __import__('company.foo.somemod') py.test.run(mod) A quick glance in the py.test source doesn't seem like a trivial thing. IPython introspection did not give me any clue either. Is there a way to do this at all? I did try py.test.cmdline.main(['...']), but that accepts only file path, not the Python module object itself. -srid From holger at merlinux.eu Thu Aug 5 23:06:52 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 5 Aug 2010 23:06:52 +0200 Subject: [py-dev] py.test api - Running tests in a module object? In-Reply-To: <4C5B2316.7050909@activestate.com> References: <4C5B2316.7050909@activestate.com> Message-ID: <20100805210652.GY1914@trillke.net> Hi Sridhar, On Thu, Aug 05, 2010 at 13:46 -0700, Sridhar Ratnakumar wrote: > I am trying to run py.test on a given module object dynamically. > > mod = __import__('company.foo.somemod') > py.test.run(mod) > > A quick glance in the py.test source doesn't seem like a trivial thing. > IPython introspection did not give me any clue either. > > Is there a way to do this at all? I did try > py.test.cmdline.main(['...']), but that accepts only file path, not the > Python module object itself. there currently is no direct support for running tests in python modules. py.test basically always starts from the file system. Does it help you to try to fish the file from somemod.__file__ and pass this to cmdline.main()? You only expect it to collect tests of a single module, right? I guess we could add some more direct support for this if you continue to have the need (please create an issue if so). cheers, holger From sridharr at activestate.com Thu Aug 5 23:24:07 2010 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Thu, 05 Aug 2010 14:24:07 -0700 Subject: [py-dev] py.test api - Running tests in a module object? In-Reply-To: <20100805210652.GY1914@trillke.net> References: <4C5B2316.7050909@activestate.com> <20100805210652.GY1914@trillke.net> Message-ID: <4C5B2BF7.8070107@activestate.com> On 8/5/2010 2:06 PM, holger krekel wrote: > On Thu, Aug 05, 2010 at 13:46 -0700, Sridhar Ratnakumar wrote: >> > I am trying to run py.test on a given module object dynamically. >> > >> > mod = __import__('company.foo.somemod') >> > py.test.run(mod) >> > >> > A quick glance in the py.test source doesn't seem like a trivial thing. >> > IPython introspection did not give me any clue either. >> > >> > Is there a way to do this at all? I did try >> > py.test.cmdline.main(['...']), but that accepts only file path, not the >> > Python module object itself. > there currently is no direct support for running tests in python modules. > py.test basically always starts from the file system. Does it help you > to try to fish the file from somemod.__file__ and pass this to cmdline.main()? > You only expect it to collect tests of a single module, right? > I guess we could add some more direct support for this if > you continue to have the need (please create an issue if so). Hmm, __file__ is a workaround, but it seems to work fine for my use case. I was just wondering if an API was exposed. I am happy with __file__ for now. -srid From holger at merlinux.eu Thu Aug 5 23:28:23 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 5 Aug 2010 23:28:23 +0200 Subject: [py-dev] py.test api - Running tests in a module object? In-Reply-To: <4C5B2BF7.8070107@activestate.com> References: <4C5B2316.7050909@activestate.com> <20100805210652.GY1914@trillke.net> <4C5B2BF7.8070107@activestate.com> Message-ID: <20100805212823.GB1914@trillke.net> On Thu, Aug 05, 2010 at 14:24 -0700, Sridhar Ratnakumar wrote: > On 8/5/2010 2:06 PM, holger krekel wrote: >> On Thu, Aug 05, 2010 at 13:46 -0700, Sridhar Ratnakumar wrote: >>> > I am trying to run py.test on a given module object dynamically. >>> > >>> > mod = __import__('company.foo.somemod') >>> > py.test.run(mod) >>> > >>> > A quick glance in the py.test source doesn't seem like a trivial thing. >>> > IPython introspection did not give me any clue either. >>> > >>> > Is there a way to do this at all? I did try >>> > py.test.cmdline.main(['...']), but that accepts only file path, not the >>> > Python module object itself. >> there currently is no direct support for running tests in python modules. >> py.test basically always starts from the file system. Does it help you >> to try to fish the file from somemod.__file__ and pass this to cmdline.main()? >> You only expect it to collect tests of a single module, right? >> I guess we could add some more direct support for this if >> you continue to have the need (please create an issue if so). > > Hmm, __file__ is a workaround, but it seems to work fine for my use > case. I was just wondering if an API was exposed. > > I am happy with __file__ for now. What do you think about automating this lookup and allowing py.test.cmdline.main([module]) maybe that's enough? best, holger From sridharr at activestate.com Thu Aug 5 23:39:42 2010 From: sridharr at activestate.com (Sridhar Ratnakumar) Date: Thu, 5 Aug 2010 14:39:42 -0700 Subject: [py-dev] py.test api - Running tests in a module object? In-Reply-To: <20100805212823.GB1914@trillke.net> References: <4C5B2316.7050909@activestate.com> <20100805210652.GY1914@trillke.net> <4C5B2BF7.8070107@activestate.com> <20100805212823.GB1914@trillke.net> Message-ID: <10C7D726-EFFB-42F4-902C-D023A20FE498@activestate.com> On 2010-08-05, at 2:28 PM, holger krekel wrote: > On Thu, Aug 05, 2010 at 14:24 -0700, Sridhar Ratnakumar wrote: >> On 8/5/2010 2:06 PM, holger krekel wrote: >>> On Thu, Aug 05, 2010 at 13:46 -0700, Sridhar Ratnakumar wrote: >>>>> I am trying to run py.test on a given module object dynamically. >>>>> >>>>> mod = __import__('company.foo.somemod') >>>>> py.test.run(mod) >>>>> >>>>> A quick glance in the py.test source doesn't seem like a trivial thing. >>>>> IPython introspection did not give me any clue either. >>>>> >>>>> Is there a way to do this at all? I did try >>>>> py.test.cmdline.main(['...']), but that accepts only file path, not the >>>>> Python module object itself. >>> there currently is no direct support for running tests in python modules. >>> py.test basically always starts from the file system. Does it help you >>> to try to fish the file from somemod.__file__ and pass this to cmdline.main()? >>> You only expect it to collect tests of a single module, right? >>> I guess we could add some more direct support for this if >>> you continue to have the need (please create an issue if so). >> >> Hmm, __file__ is a workaround, but it seems to work fine for my use >> case. I was just wondering if an API was exposed. >> >> I am happy with __file__ for now. > > What do you think about automating this lookup and allowing > > py.test.cmdline.main([module]) > > maybe that's enough? That might have helped, but then - just now, I rewrote some routines in my code to simply rely on .py file paths instead of modules. This simplified the code a bit. So now I have come to prefer file paths. :-) If I ever have the need for running tests on module/class/collection-of-funcs objects, I will be sure to open a feature request. Thanks. -srid From issues-noreply at bitbucket.org Fri Aug 6 01:46:12 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Thu, 05 Aug 2010 23:46:12 -0000 Subject: [py-dev] New issue 114 in py-trunk: cmdline(..) uses wrong program name Message-ID: --- you can reply above this line --- New issue 114: cmdline(..) uses wrong program name http://bitbucket.org/hpk42/py-trunk/issue/114/cmdline-uses-wrong-program-name Sridhar Ratnakumar / srid on Fri, 6 Aug 2010 01:46:12 +0200: Description: I am invoking py.test via py.test.cmdline(). When there is an error in command line, the following is printed: {{{ usage: boa [options] [file_or_dir] [file_or_dir] [...] boa: error: no such option: --junitlxml }}} "boa" is the name of *my* program, which py.test.cmdline() is stealing. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From flub at devork.be Sat Aug 7 11:52:24 2010 From: flub at devork.be (Floris Bruynooghe) Date: Sat, 7 Aug 2010 10:52:24 +0100 Subject: [py-dev] Generic funcarg hook Message-ID: <20100807095224.GA14232@laurie.devork.be> Hi I was talking to ronny on IRC about wanting a generic funcarg hook and he asked me to post my use case here as you are still thinking about the API for it. Since there is no generic funcarg hook now this is how I currently create the tests: def pytest_funcarg__tdata(request): fname = os.path.join(DATADIR, requst.function.__name__+'.ext') with file(fname) as fd: obj = fd.read() return obj def test_spam(tdata): assert func_under_test(tdata) == 'foo' def test_eggs(tdata): assert func_under_test(tdata) == 'bar' Before I started writing it this way I was looking for a generic funcarg hook since I think this would have been clearer if I could have used "spam" and "eggs" as funcargs and still create the object for them from one function rather then having to spell it out for each one. So I'm hoping that in a future version you might add an API to do allow something like this. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From memedough at gmail.com Sun Aug 8 10:27:53 2010 From: memedough at gmail.com (meme dough) Date: Sun, 8 Aug 2010 18:27:53 +1000 Subject: [py-dev] pytest-cov Message-ID: Hi, The --cov option is now filesystem paths as that should be how it will work with the upcoming source option from coverage. Help text updated. Warning when nothing to report on. Reports on generation of html, xml and annotated source. Minimised imports. Haven't moved DistMaster / DistSlave yet as found easier for minimising imports if not in pytest-cov, may make a separate module there, will consider further. :) From holger at merlinux.eu Tue Aug 10 10:50:00 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 10 Aug 2010 10:50:00 +0200 Subject: [py-dev] pytest-cov In-Reply-To: References: Message-ID: <20100810085000.GD1914@trillke.net> Hi Meme, On Sun, Aug 08, 2010 at 18:27 +1000, meme dough wrote: > Hi, > > The --cov option is now filesystem paths as that should be how it will > work with the upcoming source option from coverage. Help text > updated. FYI i am fine (and interested, i guess) in both versions: specifying a file system path as well as a python import path. If in doubt filesystem is probably more consistent with py.test's way of looking at tests (almost all related options specify fs paths) so i guess this is ok for now. will try your latest release latest when back from holiday which i am going for today for 2-3 weeks :) best, holger > Warning when nothing to report on. > > Reports on generation of html, xml and annotated source. > > Minimised imports. > > Haven't moved DistMaster / DistSlave yet as found easier for > minimising imports if not in pytest-cov, may make a separate module > there, will consider further. > > :) > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From holger at merlinux.eu Tue Aug 10 11:01:09 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 10 Aug 2010 11:01:09 +0200 Subject: [py-dev] Generic funcarg hook In-Reply-To: <20100807095224.GA14232@laurie.devork.be> References: <20100807095224.GA14232@laurie.devork.be> Message-ID: <20100810090109.GF1914@trillke.net> Hi Floris, to be sure i understand your use-case: could you invent an API/example that you'd like to see working? FYI, i am considering introducing a slightly higher level mechanism on top of funcargs, dealing with (parametrizable) resources. Something like: @py.test.mark.resourcefactory(scope="session", argnames=['foo', 'bar']) def myfactory(request): if request.argname == "foo": ... elif request.argname == "bar": ... The request object would be what pytest_funcarg__NAME get but this would allow free naming and have a single factory become responsible for multiple funcargs and allow to declare scope reather than having to invoke request.cached_setup(). Instead of the latter, one could write "request.addfinalizer()" which would default to the declared scope. Happy about any thoughts on this but mainly i mention this consideration here in case it would fit with your use case. best, holger On Sat, Aug 07, 2010 at 10:52 +0100, Floris Bruynooghe wrote: > Hi > > I was talking to ronny on IRC about wanting a generic funcarg hook and > he asked me to post my use case here as you are still thinking about > the API for it. Since there is no generic funcarg hook now this is > how I currently create the tests: > > > def pytest_funcarg__tdata(request): > fname = os.path.join(DATADIR, requst.function.__name__+'.ext') > with file(fname) as fd: > obj = fd.read() > return obj > > def test_spam(tdata): > assert func_under_test(tdata) == 'foo' > > def test_eggs(tdata): > assert func_under_test(tdata) == 'bar' > > > Before I started writing it this way I was looking for a generic > funcarg hook since I think this would have been clearer if I could > have used "spam" and "eggs" as funcargs and still create the object > for them from one function rather then having to spell it out for each > one. So I'm hoping that in a future version you might add an API to > do allow something like this. > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From holger at merlinux.eu Tue Aug 10 12:10:13 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 10 Aug 2010 12:10:13 +0200 Subject: [py-dev] parametrized resources (Re: Generic funcarg hook) In-Reply-To: <20100810090109.GF1914@trillke.net> References: <20100807095224.GA14232@laurie.devork.be> <20100810090109.GF1914@trillke.net> Message-ID: <20100810101013.GG1914@trillke.net> Hi Floris, all, On Tue, Aug 10, 2010 at 11:01 +0200, holger krekel wrote: > FYI, i am considering introducing a slightly higher level > mechanism on top of funcargs, dealing with (parametrizable) > resources. Something like: > > @py.test.mark.resourcefactory(scope="session", argnames=['foo', 'bar']) > def myfactory(request): > if request.argname == "foo": > ... > elif request.argname == "bar": > ... > > The request object would be what pytest_funcarg__NAME get but > this would allow free naming and have a single factory become > responsible for multiple funcargs and allow to declare scope > reather than having to invoke request.cached_setup(). Instead > of the latter, one could write "request.addfinalizer()" which > would default to the declared scope. just to be clear, the test function would look like: def test_function(foo): ... foo is initialized per-session, created per the factory above def test_function2(foo, bar): ... foo and bare are created by two invocations to the factory above Moreover, regarding the "parametrized resources" aspect, there would be a new decorator: @py.test.mark.parametrize(foo=iterable) def test_function(foo): ... invoked for multiple foo instances The idea is to be able to avoid pytest_generate_tests functions in a number of cases. Both the current funcarg-mechanism and the generate-tests mechanism would continue to exist but be considered "lower level", i.e. upcoming examples on the web page would use the new more declarative approach, requiring less API knowledge and naming freedom to use them. any comments and particularly real use cases very welcome! best, holger > Happy about any thoughts on this but mainly i mention this > consideration here in case it would fit with your use case. > > best, > holger > > > On Sat, Aug 07, 2010 at 10:52 +0100, Floris Bruynooghe wrote: > > Hi > > > > I was talking to ronny on IRC about wanting a generic funcarg hook and > > he asked me to post my use case here as you are still thinking about > > the API for it. Since there is no generic funcarg hook now this is > > how I currently create the tests: > > > > > > def pytest_funcarg__tdata(request): > > fname = os.path.join(DATADIR, requst.function.__name__+'.ext') > > with file(fname) as fd: > > obj = fd.read() > > return obj > > > > def test_spam(tdata): > > assert func_under_test(tdata) == 'foo' > > > > def test_eggs(tdata): > > assert func_under_test(tdata) == 'bar' > > > > > > Before I started writing it this way I was looking for a generic > > funcarg hook since I think this would have been clearer if I could > > have used "spam" and "eggs" as funcargs and still create the object > > for them from one function rather then having to spell it out for each > > one. So I'm hoping that in a future version you might add an API to > > do allow something like this. > > > > -- > > Debian GNU/Linux -- The Power of Freedom > > www.debian.org | www.gnu.org | www.kernel.org > > _______________________________________________ > > py-dev mailing list > > py-dev at codespeak.net > > http://codespeak.net/mailman/listinfo/py-dev > > > > -- > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- From holger at merlinux.eu Wed Aug 11 09:28:41 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 11 Aug 2010 09:28:41 +0200 Subject: [py-dev] survey results unittest/py.test/nose/... Message-ID: <20100811072841.GJ1914@trillke.net> Hi all, came across this activestate link which recently surveyed usage of test automation frameworks: http://www.activestate.com/blog/2010/07/survey-says-selenium-nose-most-popular-test-framework I am pleasantly surprised to find py.test come ahead of nose and don't quite get the title and the summary which seem to indicate otherwise. Probably I am missing something? best, holger From flub at devork.be Wed Aug 11 19:58:22 2010 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 11 Aug 2010 18:58:22 +0100 Subject: [py-dev] Generic funcarg hook In-Reply-To: <20100810090109.GF1914@trillke.net> References: <20100807095224.GA14232@laurie.devork.be> <20100810090109.GF1914@trillke.net> Message-ID: <20100811175822.GA28339@laurie.devork.be> Hello Holger On Tue, Aug 10, 2010 at 11:01:09AM +0200, holger krekel wrote: > to be sure i understand your use-case: could you invent > an API/example that you'd like to see working? def pytest_funcarg_factory(request): if request.funcargname == 'foo': return object() elif request.funcargname == 'bar': return object() else: raise KeyError() And when it raises a KeyError (or does not exist) it would fall back to the normal pytest_funcarg__name functions. So using a factory like this would still be the exception rather then the rule, most funcargs would come from pytest_funcarg__name functions. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From flub at devork.be Wed Aug 11 20:28:43 2010 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 11 Aug 2010 19:28:43 +0100 Subject: [py-dev] parametrized resources (Re: Generic funcarg hook) In-Reply-To: <20100810101013.GG1914@trillke.net> References: <20100807095224.GA14232@laurie.devork.be> <20100810090109.GF1914@trillke.net> <20100810101013.GG1914@trillke.net> Message-ID: <20100811182843.GB28339@laurie.devork.be> On Tue, Aug 10, 2010 at 12:10:13PM +0200, holger krekel wrote: > On Tue, Aug 10, 2010 at 11:01 +0200, holger krekel wrote: > > FYI, i am considering introducing a slightly higher level > > mechanism on top of funcargs, dealing with (parametrizable) > > resources. Something like: > > > > @py.test.mark.resourcefactory(scope="session", argnames=['foo', 'bar']) > > def myfactory(request): > > if request.argname == "foo": > > ... > > elif request.argname == "bar": > > ... [...] > Moreover, regarding the "parametrized resources" aspect, > there would be a new decorator: > > @py.test.mark.parametrize(foo=iterable) > def test_function(foo): > ... invoked for multiple foo instances Not sure how much I like these examples. But the use of decorators could make things clearer maybe, I think something like this might make things easier to write: @py.test.cached(scope='session') # or py.test.mark.cached def pytest_funcarg__foo(request): pass Here the actual function would only be called once for the session. @py.test.parametrize(iterable) def pytest_funcarg__foo(request, args, from, iterable): pass In this case the function would be called as many times as the iterable has items. Each item in the iterable would be the arguments to pass to the function. The iterable might have to work both with ['arg1', 'arg2', ...] as well as [('spam1', 'eggs1'), ('spam2', 'eggs2'), ...] to be easy to use. And of course nesting these decorators would be useful too. Here's how I'd use this in real code I have: @py.test.cached(scope='session') @py.test.parametrize(['v1', 'v2c', 'v3']) def pytest_funcarg__snmpcfg(request, version): if version in ('v1', 'v2c'): cfg = check_snmp_v12(version) elif version == 'v3': cfg = check_snmp_v3() if not cfg: py.test.skip('No SNMP%s agent available' % version) return SnmpWrapper(cfg) I expect this function to be called 3 times during the whole session and any test function asking for "snmpcfg" will get called 3 times (some of those 3 might skip instead in this case). This should probably work independed of the order of the decorators (the order shown reads a little funny I guess). Anyway, just my toughts after reading your description Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From fuzzyman at voidspace.org.uk Fri Aug 13 16:28:54 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 13 Aug 2010 15:28:54 +0100 Subject: [py-dev] parametrized resources (Re: Generic funcarg hook) In-Reply-To: <20100810101013.GG1914@trillke.net> References: <20100807095224.GA14232@laurie.devork.be> <20100810090109.GF1914@trillke.net> <20100810101013.GG1914@trillke.net> Message-ID: <4C6556A6.5040708@voidspace.org.uk> On 10/08/2010 11:10, holger krekel wrote: > Hi Floris, all, > > On Tue, Aug 10, 2010 at 11:01 +0200, holger krekel wrote: > >> FYI, i am considering introducing a slightly higher level >> mechanism on top of funcargs, dealing with (parametrizable) >> resources. Something like: >> >> @py.test.mark.resourcefactory(scope="session", argnames=['foo', 'bar']) >> def myfactory(request): >> if request.argname == "foo": >> ... >> elif request.argname == "bar": >> ... >> >> The request object would be what pytest_funcarg__NAME get but >> this would allow free naming and have a single factory become >> responsible for multiple funcargs and allow to declare scope >> reather than having to invoke request.cached_setup(). Instead >> of the latter, one could write "request.addfinalizer()" which >> would default to the declared scope. >> > just to be clear, the test function would look like: > > def test_function(foo): > ... foo is initialized per-session, created per the factory above > > def test_function2(foo, bar): > ... foo and bare are created by two invocations to the factory above > > Moreover, regarding the "parametrized resources" aspect, > there would be a new decorator: > > @py.test.mark.parametrize(foo=iterable) > def test_function(foo): > ... invoked for multiple foo instances > > The idea is to be able to avoid pytest_generate_tests functions > in a number of cases. > > Hey all, For unittest(2) there is an implementation of parametrized tests that already exists as a plugin. http://hg.python.org/unittest2/file/tip/unittest2/plugins/moduleloading.py The decorator form is basically identical to the suggested form above: from unittest2.plugins.moduleloading import params @params(iterable) def test_function(arg1, arg2, arg3): ... test_function will be expanded into one test per member in iterable at test load time. This is all experimental, i.e. we don't know yet if any of this will come into core unittest or live as a plugin forever. The plugin also supports test generators, but unlike test generators in nose these are expanded at test *load* time rather than test execution time. They are supported at the moment because a lot of the people really like the generator syntax for creating tests. from unittest2.plugins.moduleloading import testGenerator @ testGenerator def test_function(): for value in range(5): yield other_function, (value,) All the best, Michael > Both the current funcarg-mechanism and the generate-tests mechanism > would continue to exist but be considered "lower level", i.e. upcoming > examples on the web page would use the new more declarative approach, > requiring less API knowledge and naming freedom to use them. > > any comments and particularly real use cases very welcome! > > best, > holger > > >> Happy about any thoughts on this but mainly i mention this >> consideration here in case it would fit with your use case. >> >> best, >> holger >> >> >> On Sat, Aug 07, 2010 at 10:52 +0100, Floris Bruynooghe wrote: >> >>> Hi >>> >>> I was talking to ronny on IRC about wanting a generic funcarg hook and >>> he asked me to post my use case here as you are still thinking about >>> the API for it. Since there is no generic funcarg hook now this is >>> how I currently create the tests: >>> >>> >>> def pytest_funcarg__tdata(request): >>> fname = os.path.join(DATADIR, requst.function.__name__+'.ext') >>> with file(fname) as fd: >>> obj = fd.read() >>> return obj >>> >>> def test_spam(tdata): >>> assert func_under_test(tdata) == 'foo' >>> >>> def test_eggs(tdata): >>> assert func_under_test(tdata) == 'bar' >>> >>> >>> Before I started writing it this way I was looking for a generic >>> funcarg hook since I think this would have been clearer if I could >>> have used "spam" and "eggs" as funcargs and still create the object >>> for them from one function rather then having to spell it out for each >>> one. So I'm hoping that in a future version you might add an API to >>> do allow something like this. >>> >>> -- >>> Debian GNU/Linux -- The Power of Freedom >>> www.debian.org | www.gnu.org | www.kernel.org >>> _______________________________________________ >>> py-dev mailing list >>> py-dev at codespeak.net >>> http://codespeak.net/mailman/listinfo/py-dev >>> >>> >> -- >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev >> >> > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20100813/fbd4f08e/attachment.htm From issues-noreply at bitbucket.org Sun Aug 15 16:29:43 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sun, 15 Aug 2010 14:29:43 -0000 Subject: [py-dev] New issue 115 in py-trunk: Catch-all exceptions don't make an exception for GeneratorExit Message-ID: --- you can reply above this line --- New issue 115: Catch-all exceptions don't make an exception for GeneratorExit http://bitbucket.org/hpk42/py-trunk/issue/115/catch-all-exceptions-dont-make-an-exception-for Floris Bruynooghe / flub on Sun, 15 Aug 2010 16:29:43 +0200: Description: Hi pylib seems to often use {{{ try: ... except (KeyboardInterrupt, SystemExit): raise except: ... }}} However this currently misses GeneratorExit and might miss other exceptions which don't (and shouldn't) inherit from Exception in the future. However the hierarchy only got rearranged in python 2.5 and GeneratorExit was only present since 2.5. So maybe this can't be solved until 2.4 is no longer supported. Regards Floris Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From flub at devork.be Mon Aug 16 02:25:57 2010 From: flub at devork.be (Floris Bruynooghe) Date: Mon, 16 Aug 2010 01:25:57 +0100 Subject: [py-dev] Advanced assert equal Message-ID: <20100816002557.GA12335@laurie.devork.be> Hi Ever since unittest grew it's .assertSequenceEqual() and .assertMultilineEqual() I've been jealous of it. So this weekend I've looked into the py.test code and made an attempt at getting this into my favourite testing tool. The attached patch makes compare equal a special case and checks if the two arguments to it are both a list, text or dict and tries to generate a nicer explanation text for them. The patch is more like a proof of concept then a final implementation, I may have done some very strange or silly things as I'm not familiar with the code. It would be great to get feedback, both on the general concept and the actual implementation (particularly note the way I had to hack _format_explanation() in assertion.py). Some of the rough edges I can think off right now: (i) no idea how comparisons and nested calls work together, (ii) no attempt is made to limit the output from difflib so the screen doesn't get flooded. There's probably many more. I hope this can be useful Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -------------- next part -------------- A non-text attachment was scrubbed... Name: py.test.diff Type: text/x-diff Size: 6744 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20100816/672c190c/attachment-0001.bin From holger at merlinux.eu Mon Aug 16 09:10:16 2010 From: holger at merlinux.eu (holger krekel) Date: Mon, 16 Aug 2010 09:10:16 +0200 Subject: [py-dev] Advanced assert equal In-Reply-To: <20100816002557.GA12335@laurie.devork.be> References: <20100816002557.GA12335@laurie.devork.be> Message-ID: <20100816071015.GR1914@trillke.net> Hey Floris, nice. i also thought about improving reporting for particular types of assert-expressions. Will take a look at your code after holiday and maybe Benjamin can also take a look or make a suggestion on how to best make assert expression-reporting customizable. cheers, holger On Mon, Aug 16, 2010 at 01:25 +0100, Floris Bruynooghe wrote: > Hi > > Ever since unittest grew it's .assertSequenceEqual() and > .assertMultilineEqual() I've been jealous of it. So this weekend I've > looked into the py.test code and made an attempt at getting this into > my favourite testing tool. > > The attached patch makes compare equal a special case and checks if > the two arguments to it are both a list, text or dict and tries to > generate a nicer explanation text for them. The patch is more like a > proof of concept then a final implementation, I may have done some > very strange or silly things as I'm not familiar with the code. It > would be great to get feedback, both on the general concept and the > actual implementation (particularly note the way I had to hack > _format_explanation() in assertion.py). > > Some of the rough edges I can think off right now: (i) no idea how > comparisons and nested calls work together, (ii) no attempt is made to > limit the output from difflib so the screen doesn't get flooded. > There's probably many more. > > I hope this can be useful > Floris > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > diff --git a/py/_code/_assertionnew.py b/py/_code/_assertionnew.py > --- a/py/_code/_assertionnew.py > +++ b/py/_code/_assertionnew.py > @@ -5,6 +5,8 @@ This should replace _assertionold.py eve > > import sys > import ast > +import difflib > +import pprint > > import py > from py._code.assertion import _format_explanation, BuiltinAssertionError > @@ -164,8 +166,6 @@ class DebugInterpreter(ast.NodeVisitor): > left_explanation, left_result = self.visit(left) > got_result = False > for op, next_op in zip(comp.ops, comp.comparators): > - if got_result and not result: > - break > next_explanation, next_result = self.visit(next_op) > op_symbol = operator_map[op.__class__] > explanation = "%s %s %s" % (left_explanation, op_symbol, > @@ -177,11 +177,56 @@ class DebugInterpreter(ast.NodeVisitor): > __exprinfo_right=next_result) > except Exception: > raise Failure(explanation) > - else: > - got_result = True > + if not result: > + break > left_explanation, left_result = next_explanation, next_result > + if op_symbol == "==": > + new_expl = self._explain_equal(left_result, next_result, > + left_explanation, next_explanation) > + if new_expl: > + explanation = new_expl > return explanation, result > > + def _explain_equal(self, left, right, left_repr, right_repr): > + """Make a specialised explanation for comapare equal""" > + if type(left) != type(right): > + return None > + explanation = [] > + if len(left_repr) > 30: > + left_repr = left_repr[:27] + '...' > + if len(right_repr) > 30: > + right_repr = right_repr[:27] + '...' > + explanation += ['%s == %s' % (left_repr, right_repr)] > + issquence = lambda x: isinstance(x, (list, tuple)) > + istext = lambda x: isinstance(x, basestring) > + isdict = lambda x: isinstance(x, dict) > + if issquence(left): > + for i in xrange(min(len(left), len(right))): > + if left[i] != right[i]: > + explanation += ['First differing item %s: %s != %s' % > + (i, left[i], right[i])] > + break > + if len(left) > len(right): > + explanation += ['Left contains more items, ' > + 'first extra item: %s' % left[len(right)]] > + elif len(left) < len(right): > + explanation += ['Right contains more items, ' > + 'first extra item: %s' % right[len(right)]] > + explanation += [line.strip('\n') for line in > + difflib.ndiff(pprint.pformat(left).splitlines(), > + pprint.pformat(right).splitlines())] > + elif istext(left): > + explanation += [line.strip('\n') for line in > + difflib.ndiff(left.splitlines(), > + right.splitlines())] > + elif isdict(left): > + explanation += [line.strip('\n') for line in > + difflib.ndiff(pprint.pformat(left).splitlines(), > + pprint.pformat(right).splitlines())] > + else: > + return None # No specialised knowledge > + return '\n=='.join(explanation) > + > def visit_BoolOp(self, boolop): > is_or = isinstance(boolop.op, ast.Or) > explanations = [] > diff --git a/py/_code/assertion.py b/py/_code/assertion.py > --- a/py/_code/assertion.py > +++ b/py/_code/assertion.py > @@ -10,7 +10,7 @@ def _format_explanation(explanation): > # escape newlines not followed by { and } > lines = [raw_lines[0]] > for l in raw_lines[1:]: > - if l.startswith('{') or l.startswith('}'): > + if l.startswith('{') or l.startswith('}') or l.startswith('=='): > lines.append(l) > else: > lines[-1] += '\\n' + l > @@ -28,11 +28,14 @@ def _format_explanation(explanation): > stackcnt[-1] += 1 > stackcnt.append(0) > result.append(' +' + ' '*(len(stack)-1) + s + line[1:]) > - else: > + elif line.startswith('}'): > assert line.startswith('}') > stack.pop() > stackcnt.pop() > result[stack[-1]] += line[1:] > + else: > + assert line.startswith('==') > + result.append(' ' + line.strip('==')) > assert len(stack) == 1 > return '\n'.join(result) > > diff --git a/testing/code/test_assertionnew.py b/testing/code/test_assertionnew.py > new file mode 100644 > --- /dev/null > +++ b/testing/code/test_assertionnew.py > @@ -0,0 +1,74 @@ > +import sys > + > +import py > +from py._code._assertionnew import interpret > + > + > +def getframe(): > + """Return the frame of the caller as a py.code.Frame object""" > + return py.code.Frame(sys._getframe(1)) > + > + > +def setup_module(mod): > + py.code.patch_builtins(assertion=True, compile=False) > + > + > +def teardown_module(mod): > + py.code.unpatch_builtins(assertion=True, compile=False) > + > + > +def test_assert_simple(): > + # Simply test that this way of testing works > + a = 0 > + b = 1 > + r = interpret('assert a == b', getframe()) > + assert r == 'assert 0 == 1' > + > + > +def test_assert_list(): > + r = interpret('assert [0, 1] == [0, 2]', getframe()) > + msg = ('assert [0, 1] == [0, 2]\n' > + ' First differing item 1: 1 != 2\n' > + ' - [0, 1]\n' > + ' ? ^\n' > + ' + [0, 2]\n' > + ' ? ^') > + print r > + assert r == msg > + > + > +def test_assert_string(): > + r = interpret('assert "foo and bar" == "foo or bar"', getframe()) > + msg = ("assert 'foo and bar' == 'foo or bar'\n" > + " - foo and bar\n" > + " ? ^^^\n" > + " + foo or bar\n" > + " ? ^^") > + print r > + assert r == msg > + > + > +def test_assert_multiline_string(): > + a = 'foo\nand bar\nbaz' > + b = 'foo\nor bar\nbaz' > + r = interpret('assert a == b', getframe()) > + msg = ("assert 'foo\\nand bar\\nbaz' == 'foo\\nor bar\\nbaz'\n" > + ' foo\n' > + ' - and bar\n' > + ' + or bar\n' > + ' baz') > + print r > + assert r == msg > + > + > +def test_assert_dict(): > + a = {'a': 0, 'b': 1} > + b = {'a': 0, 'c': 2} > + r = interpret('assert a == b', getframe()) > + msg = ("assert {'a': 0, 'b': 1} == {'a': 0, 'c': 2}\n" > + " - {'a': 0, 'b': 1}\n" > + " ? ^ ^\n" > + " + {'a': 0, 'c': 2}\n" > + " ? ^ ^") > + print r > + assert r == msg > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev -- From Ronny.Pfannschmidt at gmx.de Mon Aug 16 13:29:13 2010 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Mon, 16 Aug 2010 13:29:13 +0200 Subject: [py-dev] Advanced assert equal In-Reply-To: <20100816002557.GA12335@laurie.devork.be> References: <20100816002557.GA12335@laurie.devork.be> Message-ID: <1281958153.12940.5.camel@klappe2> On Mon, 2010-08-16 at 01:25 +0100, Floris Bruynooghe wrote: > Hi > > Ever since unittest grew it's .assertSequenceEqual() and > .assertMultilineEqual() I've been jealous of it. So this weekend I've > looked into the py.test code and made an attempt at getting this into > my favourite testing tool. > > The attached patch makes compare equal a special case and checks if > the two arguments to it are both a list, text or dict and tries to > generate a nicer explanation text for them. The patch is more like a > proof of concept then a final implementation, I may have done some > very strange or silly things as I'm not familiar with the code. It > would be great to get feedback, both on the general concept and the > actual implementation (particularly note the way I had to hack > _format_explanation() in assertion.py). > I think it will be helpful to have some kind of hook to add more explain-functions In particular, cause there are many more build-in types to manage, and i have at least 2 projects where custom compare-explain is helpfull another wishlist item i see is the rest of rich compare i.e. <, >, <=, >=, != > Some of the rough edges I can think off right now: (i) no idea how > comparisons and nested calls work together, (ii) no attempt is made to > limit the output from difflib so the screen doesn't get flooded. > There's probably many more. > > I hope this can be useful > Floris > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev From flub at devork.be Mon Aug 16 15:51:54 2010 From: flub at devork.be (Floris Bruynooghe) Date: Mon, 16 Aug 2010 14:51:54 +0100 Subject: [py-dev] Advanced assert equal In-Reply-To: <1281958153.12940.5.camel@klappe2> References: <20100816002557.GA12335@laurie.devork.be> <1281958153.12940.5.camel@klappe2> Message-ID: <20100816135154.GA24594@laurie.devork.be> On Mon, Aug 16, 2010 at 01:29:13PM +0200, Ronny Pfannschmidt wrote: > On Mon, 2010-08-16 at 01:25 +0100, Floris Bruynooghe wrote: > > The attached patch makes compare equal a special case and checks if > > the two arguments to it are both a list, text or dict and tries to > > generate a nicer explanation text for them. The patch is more like a > > proof of concept then a final implementation, I may have done some > > very strange or silly things as I'm not familiar with the code. It > > would be great to get feedback, both on the general concept and the > > actual implementation (particularly note the way I had to hack > > _format_explanation() in assertion.py). > > I think it will be helpful to have some kind of hook to add more > explain-functions Adding hooks should be possible, looking at all the .visit_*() functions it would seem only one hook is required, unless separate hooks for each rich compare operator are deemed useful. The trickiest bit I think is how to produce multiline explanations. _format_explanation() concatenates all newlines. Having only special cases for \n{ and \n} which is used by .visit_Call() to force nested and indented newlines. In the patch I added \n== for this but a more general one is probably required, something like \n> or \n~ could work I guess. This could be completely hidden from the hook however, by returning a list for each line to be printed, the caller of the hook would then join these up correctly so that _format_explanation() will add newlines and indentation correctly. A possible api for the hook could be: def pytest_assert_compare(op, left, right, left_repr, right_repr): """Customise compare Return None for no custom compare, otherwise return a list of strings. The strings will be joined by newlines but any newlines *in* a string will be escaped. """ pass I guess the reprs are not really necessary if there's an easy way to make them. It's just that I used them in my original patch. Another option is to encapsulate the arguments into an object that also knows how the builtin types and operators are compared, something like: class CompareItem(object): def __init__(self, op, left, right, ...): self.op = op self.left = left self.right = right ... def default(self): if type(self.left) != type(self.right): return None if self.op == '==': if isinstance(self.left, (list, tuple)): return self.sequence_equal() elif isinstance(self.left, basestring): return self.string_equal() ... elif self.op == '!=': ... def sequence_equal(self): pass def string_equal(self): pass ... This would allow pytest_assert_compare() to use those methods as part of the implementation. There's also the question of who should truncate large amounts of data (e.g. screenfulls of diffs): the hook itself, the caller of the hook or _format_explanation()? Probably one of the first two to get rid of the memory usage as soon as possible. > In particular, cause there are many more build-in types to manage, > and i have at least 2 projects where custom compare-explain is helpfull > > another wishlist item i see is the rest of rich compare > i.e. <, >, <=, >=, != Sure, all builtin types and operators should ideally be supported by default as best as possible. I just started with some I wanted most. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From Ronny.Pfannschmidt at gmx.de Tue Aug 17 12:54:53 2010 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Tue, 17 Aug 2010 12:54:53 +0200 Subject: [py-dev] [proposal] extended information collection Message-ID: <1282042493.12940.16.camel@klappe2> Recently i noticed a new need. The collecting/asserting various kinds of data during a testrun. I noticed the following (partially hpyothetical) cases in various projects * pip records file changes to the virtualenv it makes for testing * pypy records jit compile results/dumps * jinja2 should record asts and the compile results of templates it tests * the logcapture extension * the build-in io captureing i think i would be helpful/practical to have a common way to record those things and navigate them in extended test reporters adding propper timing information to lines/data could help even more (for having a common timeline of different event sources) since this topic is rather hard to manage i hope for some dicussion on the needs others see, as well as if/how this could add more to the testing regards Ronny From Florian.Bauer at diasemi.com Fri Aug 20 15:49:35 2010 From: Florian.Bauer at diasemi.com (Florian Bauer) Date: Fri, 20 Aug 2010 15:49:35 +0200 Subject: [py-dev] py.test doesn't like functools.partial wrappers Message-ID: <34CD30EDA5E4CB4AAA2501EB1ED319E102D705B6@charlie.diasemi.com> Hi all, I'm trying to make an existing testsuite py.test compatible. At the moment, we use nose as test runner. I stumbled upon the following (simplified example). from functools import partial def forall_cases(cases): def decorate(testfn): def gen(): for case in cases: description = case[0] args = case[1:] func = partial(testfn, *args) func.description = description yield func, gen.__name__= 'test_%s_' % testfn.__name__ # # inject the generator into the module testfn came from # gen.__module__ = testfn.__module__ return gen return decorate @forall_cases([['case1', 1, 1], ['case2', 2, 2],['case3', 3, 4]]) def test_equal(a, b): assert a == b If I run this with nosetests, I get 3 test cases, 2 pass and 1 fail. py.test tries to call inspect.getsource on the partial object, which results in a TypeError: $ py.test -v ... INTERNALERROR> INTERNALERROR> object = INTERNALERROR> INTERNALERROR> def getfile(object): INTERNALERROR> """Work out which source or compiled file an INTERNALERROR> object was d efined in.""" ... INTERNALERROR> > raise TypeError('arg is not a module, class, method, ' INTERNALERROR> 'function, traceback, frame, or INTERNALERROR> code obje ct') INTERNALERROR> E TypeError: arg is not a module, class, method, function, traceback, frame, or code object INTERNALERROR> INTERNALERROR> object = INTERNALERROR> INTERNALERROR> c:\Python26\lib\inspect.py:418: TypeError This seems to be a documented limitation of inspect.getsource (functools.partial returns a partial object, not a function). I can fix this by replacing functools.partial with code given as roughly equivalent in the python documentation: def partial(func, *args, **keywords): def newfunc(*fargs, **fkeywords): newkeywords = keywords.copy() newkeywords.update(fkeywords) return func(*(args + fargs), **newkeywords) newfunc.func = func newfunc.args = args newfunc.keywords = keywords return newfunc But I was certainly not expecting this. The default behavior of py.test is even more puzzling, as it fails silently: fbauer at MN-ENG-LT-FB ~/My Documents/Software/pytestbug1 $ py.test ============================= test session starts ============================= platform win32 -- Python 2.6.5 -- pytest-1.3.3 test path 1: c:\docume~1\fbauer\My Documents\Software\pytestbug1 test_case.py .. In my actual code, the forall_cases decorator lives in a utils module. Is there a conditional flag that can tell me whether I'm running under py.test? Then I could start experimenting with parametric tests using funcargs, while keeping the test suite runnable with nose at the moment. I still have a bug in the test suite, as I have tests passing under nose that fail under py.test... Best regards, Florian _______________________________________________________________________________________ Dialog Semiconductor GmbH Neue Str. 95 D-73230 Kirchheim Managing Director: Dr. Jalal Bagherli Chairman of the Supervisory Board: Gregorio Reyes Commercial register: Amtsgericht Stuttgart: HRB 231181 UST-ID-Nr. DE 811121668 Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. From richard.m.tew at gmail.com Sat Aug 21 03:20:44 2010 From: richard.m.tew at gmail.com (Richard Tew) Date: Sat, 21 Aug 2010 09:20:44 +0800 Subject: [py-dev] Greenlet Message-ID: Hi, In the past, I believe py included the greenlet c extension source code. I am not sure that you do anymore, or how this affects you now that it may only relate to older releases of your source code, but I would like to mention that the py library as far as I can tell effectively relicensed Python licensed code under the MIT license. Please correct me if I am wrong. http://codespeak.net/svn/py/branch/py-compat-2.5.2/py/c-extension/greenlet/ The files sourced from Stackless presumably by Christian for use with Armin in the creation of greenlet, were contributed to Stackless and subject to contributions from multiple parties, under the Python license. I am pretty sure that Christian did not, and was more than likely unable to relicense them to the MIT license on behalf of those parties. Anyway, I've brought this up with the greenlet project here: http://bitbucket.org/ambroff/greenlet/ And since that was spun off the py lib, I thought I would mention it here. Cheers, Richard. From Ronny.Pfannschmidt at gmx.de Tue Aug 24 08:43:42 2010 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Tue, 24 Aug 2010 08:43:42 +0200 Subject: [py-dev] py.test doesn't like functools.partial wrappers In-Reply-To: <34CD30EDA5E4CB4AAA2501EB1ED319E102D705B6@charlie.diasemi.com> References: <34CD30EDA5E4CB4AAA2501EB1ED319E102D705B6@charlie.diasemi.com> Message-ID: <1282632222.17701.4.camel@klappe2> On Fri, 2010-08-20 at 15:49 +0200, Florian Bauer wrote: > Hi all, > > I'm trying to make an existing testsuite py.test compatible. > At the moment, we use nose as test runner. I stumbled upon the following > (simplified example). > > from functools import partial > > def forall_cases(cases): > def decorate(testfn): > def gen(): > for case in cases: > description = case[0] > args = case[1:] > func = partial(testfn, *args) > func.description = description > yield func, > gen.__name__= 'test_%s_' % testfn.__name__ > # > # inject the generator into the module testfn came from > # > gen.__module__ = testfn.__module__ > return gen > return decorate > > > @forall_cases([['case1', 1, 1], ['case2', 2, 2],['case3', 3, 4]]) def > test_equal(a, b): > assert a == b > > > If I run this with nosetests, I get 3 test cases, 2 pass and 1 fail. > > py.test tries to call inspect.getsource on the partial object, which > results in a TypeError: > > $ py.test -v > ... > INTERNALERROR> > INTERNALERROR> object = > INTERNALERROR> > INTERNALERROR> def getfile(object): > INTERNALERROR> """Work out which source or compiled file an > INTERNALERROR> object was d > efined in.""" > ... > INTERNALERROR> > raise TypeError('arg is not a module, class, > method, ' > INTERNALERROR> 'function, traceback, frame, or > INTERNALERROR> code obje > ct') > INTERNALERROR> E TypeError: arg is not a module, class, method, > function, > traceback, frame, or code object > INTERNALERROR> > INTERNALERROR> object = > INTERNALERROR> > INTERNALERROR> c:\Python26\lib\inspect.py:418: TypeError > > This seems to be a documented limitation of inspect.getsource > (functools.partial returns a partial object, not a function). > I can fix this by replacing functools.partial with code given as roughly > equivalent in the python documentation: > > def partial(func, *args, **keywords): > def newfunc(*fargs, **fkeywords): > newkeywords = keywords.copy() > newkeywords.update(fkeywords) > return func(*(args + fargs), **newkeywords) > newfunc.func = func > newfunc.args = args > newfunc.keywords = keywords > return newfunc > > But I was certainly not expecting this. The default behavior of py.test > is even more puzzling, as it fails silently: > > fbauer at MN-ENG-LT-FB ~/My Documents/Software/pytestbug1 $ py.test > ============================= test session starts > ============================= platform win32 -- Python 2.6.5 -- > pytest-1.3.3 test path 1: c:\docume~1\fbauer\My > Documents\Software\pytestbug1 > > test_case.py .. that looks like 2 bugs cooperating for certain confusion not being able to get the source causes pytest to internally fail and those seem to be failing i'll try to make minimal replications for the pytest testsuite as i cant tell from your trace where exactly the issue orginates > > In my actual code, the forall_cases decorator lives in a utils module. > Is there a conditional flag that can tell me whether I'm running under > py.test? Then I could start experimenting with parametric tests using > funcargs, while keeping the test suite runnable with nose at the moment. > I still have a bug in the test suite, as I have tests passing under nose > that fail under py.test... > im not sure of such a flag, you could use the pytest_configure hook in a conftest to set up certain globals same goes for the per module setup hooks also you could try to use the collect hooks to strip your decorated testcases of the decorator Regards, Ronny From Ronny.Pfannschmidt at gmx.de Tue Aug 24 08:49:26 2010 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Tue, 24 Aug 2010 08:49:26 +0200 Subject: [py-dev] py.test doesn't like functools.partial wrappers In-Reply-To: <34CD30EDA5E4CB4AAA2501EB1ED319E102D705B6@charlie.diasemi.com> References: <34CD30EDA5E4CB4AAA2501EB1ED319E102D705B6@charlie.diasemi.com> Message-ID: <1282632566.17701.8.camel@klappe2> on a sidenote, according to the tests one is supposed to just use the name/description before the function in the result tuple i.e. yield name, func, ... instead of yield partial_with_desc, ... i suppose setting a global from conftest could help if you just switch cases after that on pytest you could replace your decoration with a py.test.mark.forall or something like that Regards Ronny From holger at merlinux.eu Wed Sep 1 12:55:54 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 1 Sep 2010 12:55:54 +0200 Subject: [py-dev] Greenlet In-Reply-To: References: Message-ID: <20100901105553.GC1914@trillke.net> Hi Richard, On Sat, Aug 21, 2010 at 09:20 +0800, Richard Tew wrote: > Hi, > > In the past, I believe py included the greenlet c extension source > code. I am not sure that you do anymore, or how this affects you now > that it may only relate to older releases of your source code, but I > would like to mention that the py library as far as I can tell > effectively relicensed Python licensed code under the MIT license. > Please correct me if I am wrong. That is correct but there also was a note that parts of the lib may have a different license ... > http://codespeak.net/svn/py/branch/py-compat-2.5.2/py/c-extension/greenlet/ It should have been mentioned there, not sure it was in the final release ... probably not :/ > The files sourced from Stackless presumably by Christian for use with > Armin in the creation of greenlet, were contributed to Stackless and > subject to contributions from multiple parties, under the Python > license. I am pretty sure that Christian did not, and was more than > likely unable to relicense them to the MIT license on behalf of those > parties. I guess so as well. OTOH i think MIT and Python license are not that far away from each other. In any case, greenlets are not part of the py lib for a long time now so i don't intend to do anything on that front. > Anyway, I've brought this up with the greenlet project here: > > http://bitbucket.org/ambroff/greenlet/ > > And since that was spun off the py lib, I thought I would mention it here. Thanks for the info. I agree to your comment on the issue there that it's all a bit unfortunate to concern ourselves and I also guess it makes sense to just say that greenlet is MIT *and* Python-licensed for now. So everybody who needs to care should make sure they comply to both licenses (which is not really hard and there hardly is anyone likely to ever challenge usages). just my 2cent and sorry for probably having played a part in the unprecise original license tracking. best, holger From arigo at tunes.org Wed Sep 1 15:43:01 2010 From: arigo at tunes.org (Armin Rigo) Date: Wed, 1 Sep 2010 15:43:01 +0200 Subject: [py-dev] Greenlet In-Reply-To: <20100901105553.GC1914@trillke.net> References: <20100901105553.GC1914@trillke.net> Message-ID: Hi, I have clarified the license of greenlets as found in its own svn repository subtree at http://codespeak.net/svn/greenlet/trunk/. Greenlet is no longer part of the py lib, so I don't want to go into any licensing complication; I just adopted the same license as Stackless Python. Note that most (but not all?) of the code might also be available under the MIT license from the time where it was part of the py lib; that's fine by me if you care enough to dig that out of the history. I have no control over http://bitbucket.org/ambroff/greenlet/ so if that's what you are using, you need to check with them. Armin From holger at merlinux.eu Wed Sep 1 16:00:36 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 1 Sep 2010 16:00:36 +0200 Subject: [py-dev] py.test doesn't like functools.partial wrappers In-Reply-To: <34CD30EDA5E4CB4AAA2501EB1ED319E102D705B6@charlie.diasemi.com> References: <34CD30EDA5E4CB4AAA2501EB1ED319E102D705B6@charlie.diasemi.com> Message-ID: <20100901140036.GE1914@trillke.net> Hi Florian, On Fri, Aug 20, 2010 at 15:49 +0200, Florian Bauer wrote: > Hi all, > > I'm trying to make an existing testsuite py.test compatible. > At the moment, we use nose as test runner. I stumbled upon the following > (simplified example). > > from functools import partial > > def forall_cases(cases): > def decorate(testfn): > def gen(): > for case in cases: > description = case[0] > args = case[1:] > func = partial(testfn, *args) > func.description = description > yield func, > gen.__name__= 'test_%s_' % testfn.__name__ > # > # inject the generator into the module testfn came from > # > gen.__module__ = testfn.__module__ > return gen > return decorate > > > @forall_cases([['case1', 1, 1], ['case2', 2, 2],['case3', 3, 4]]) def > test_equal(a, b): > assert a == b Hum, is it an option to rather use a different decorator that makes use of py.test's more general parametrized testing feature? See here: http://tetamap.wordpress.com/2009/05/13/parametrizing-python-tests-generalized/ for some general examples. In your case you would need to 1) define @forallcases as a simple marker, e.g.: forallcases = py.test.mark.forallcases 2) implement a pytest_generate_tests hooks that checks for the "forallcases" decorator and generates the test function invocations. The second part can just live in a conftest.py file and does not conflict with the nose-way of running tests. For the first you could try to just do something like def pytest_configure(config): import module_that_contains_forallcases module_that_contains_forallcases.forallcases = py.test.mark.forallcases If the latter lives in a conftest.py file at the root of your project or at the root of all test modules it should be executed before any test module is imported (which might import and use the forallcases decorator). > If I run this with nosetests, I get 3 test cases, 2 pass and 1 fail. > > py.test tries to call inspect.getsource on the partial object, which > results in a TypeError: > > $ py.test -v > ... > INTERNALERROR> > INTERNALERROR> object = > INTERNALERROR> > INTERNALERROR> def getfile(object): > INTERNALERROR> """Work out which source or compiled file an > INTERNALERROR> object was d > efined in.""" Can you post or attach a full traceback? I agree that a) it would be nice if nose and py.test would be more compatible here b) the error is obscure. OTOH i consider yield-based parametrization as a kind of dead-end. It certainly causes a more complex implementation for the testing machinery and can not provide features/reporting as cleanly as the above mentioned parametrized testing. > ... > INTERNALERROR> > raise TypeError('arg is not a module, class, > method, ' > INTERNALERROR> 'function, traceback, frame, or > INTERNALERROR> code obje > ct') > INTERNALERROR> E TypeError: arg is not a module, class, method, > function, > traceback, frame, or code object > INTERNALERROR> > INTERNALERROR> object = > INTERNALERROR> > INTERNALERROR> c:\Python26\lib\inspect.py:418: TypeError > > This seems to be a documented limitation of inspect.getsource > (functools.partial returns a partial object, not a function). > I can fix this by replacing functools.partial with code given as roughly > equivalent in the python documentation: > > def partial(func, *args, **keywords): > def newfunc(*fargs, **fkeywords): > newkeywords = keywords.copy() > newkeywords.update(fkeywords) > return func(*(args + fargs), **newkeywords) > newfunc.func = func > newfunc.args = args > newfunc.keywords = keywords > return newfunc > > But I was certainly not expecting this. The default behavior of py.test > is even more puzzling, as it fails silently: > > fbauer at MN-ENG-LT-FB ~/My Documents/Software/pytestbug1 $ py.test > ============================= test session starts > ============================= platform win32 -- Python 2.6.5 -- > pytest-1.3.3 test path 1: c:\docume~1\fbauer\My > Documents\Software\pytestbug1 > > test_case.py .. > > In my actual code, the forall_cases decorator lives in a utils module. > Is there a conditional flag that can tell me whether I'm running under > py.test? Then I could start experimenting with parametric tests using > funcargs, while keeping the test suite runnable with nose at the moment. > I still have a bug in the test suite, as I have tests passing under nose > that fail under py.test... There is no official way to detect if code is running within a test session. You might do something like: # contents of conftest.py def pytest_configure(config): import some_app_module some_app_module._testing = True and then do a "hasattr(some_app_module, '_testing')" check or so. However, most people don't consider it good practise to have application level code become aware if it's being tested or not. Instead people use monkeypatching or dependency-injection to modify app behaviour. HTH, holger From holger at merlinux.eu Wed Sep 1 16:40:34 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 1 Sep 2010 16:40:34 +0200 Subject: [py-dev] [proposal] extended information collection In-Reply-To: <1282042493.12940.16.camel@klappe2> References: <1282042493.12940.16.camel@klappe2> Message-ID: <20100901144034.GF1914@trillke.net> On Tue, Aug 17, 2010 at 12:54 +0200, Ronny Pfannschmidt wrote: > Recently i noticed a new need. > > The collecting/asserting various kinds of data during a testrun. > > I noticed the following (partially hpyothetical) cases in various > projects > > * pip records file changes to the virtualenv it makes for testing > * pypy records jit compile results/dumps > * jinja2 should record asts and the compile results of templates it > tests > * the logcapture extension > * the build-in io captureing > > i think i would be helpful/practical to have a common way to record > those things and navigate them in extended test reporters Not sure how you can uniformly present a user-interface to navigate such data. > adding propper timing information to lines/data could help even more > (for having a common timeline of different event sources) > > since this topic is rather hard to manage i hope for some dicussion on > the needs others see, as well as if/how this could add more to the > testing Maybe a simple storage & query mechanism for test-run related data could help. I never got around to implement this. It would provide useful to allow features like "run the last failing test from a previous py.test cmdline invocation" and to generate html reports from subsequent revisions of a project where we do a test-run for each revision and later query the result storage. This should be easily implementable as a plugin. best, holger From Florian.Bauer at diasemi.com Thu Sep 2 10:50:18 2010 From: Florian.Bauer at diasemi.com (Florian Bauer) Date: Thu, 2 Sep 2010 10:50:18 +0200 Subject: [py-dev] FW: py.test doesn't like functools.partial wrappers Message-ID: <34CD30EDA5E4CB4AAA2501EB1ED319E102FADE64@charlie.diasemi.com> ... Aargh, forgot to reply to list... -----Original Message----- From: Florian Bauer Sent: Mittwoch, 1. September 2010 16:55 To: holger krekel Subject: RE: [py-dev] py.test doesn't like functools.partial wrappers Hi Holger, > -----Original Message----- > From: holger krekel [mailto:holger at merlinux.eu] > > On Fri, Aug 20, 2010 at 15:49 +0200, Florian Bauer wrote: > > Hi all, > > > > I'm trying to make an existing testsuite py.test compatible. > > At the moment, we use nose as test runner. I stumbled upon the > > following (simplified example). > > > > from functools import partial > > > > def forall_cases(cases): > > def decorate(testfn): > > def gen(): > > for case in cases: > > description = case[0] > > args = case[1:] > > func = partial(testfn, *args) > > func.description = description > > yield func, > > gen.__name__= 'test_%s_' % testfn.__name__ > > # > > # inject the generator into the module testfn came from > > # > > gen.__module__ = testfn.__module__ > > return gen > > return decorate > > > > > > @forall_cases([['case1', 1, 1], ['case2', 2, 2],['case3', > 3, 4]]) def > > test_equal(a, b): > > assert a == b > > Hum, is it an option to rather use a different decorator that makes > use of py.test's more general parametrized testing feature? > See here: Yes, definetely. I would like to leave this decorator untouched for now (keeping nose working), and would be quite happy to have py.test using a different decorator implementation. I will try this! > > http://tetamap.wordpress.com/2009/05/13/parametrizing-python-t > ests-generalized/ > > for some general examples. In your case you would need to > 1) define @forallcases as a simple marker, e.g.: > forallcases = py.test.mark.forallcases > > 2) implement a pytest_generate_tests hooks that checks for the > "forallcases" > decorator and generates the test function invocations. > > The second part can just live in a conftest.py file and does not > conflict with the nose-way of running tests. > > For the first you could try to just do something like > > def pytest_configure(config): > import module_that_contains_forallcases > module_that_contains_forallcases.forallcases = > py.test.mark.forallcases > > If the latter lives in a conftest.py file at the root of your project > or at the root of all test modules it should be executed before any > test module is imported (which might import and use the forallcases > decorator). I will play around with this, thanks! > > If I run this with nosetests, I get 3 test cases, 2 pass and 1 fail. > > > > py.test tries to call inspect.getsource on the partial > object, which > > results in a TypeError: > > > > $ py.test -v > > ... > > INTERNALERROR> > > INTERNALERROR> object = > > INTERNALERROR> > > INTERNALERROR> def getfile(object): > > INTERNALERROR> """Work out which source or compiled file an > > INTERNALERROR> object was d > > efined in.""" > > Can you post or attach a full traceback? > I agree that a) it would be nice if nose and py.test would be more > compatible here b) the error is obscure. OTOH i consider yield-based > parametrization as a kind of dead-end. > It certainly causes a more complex implementation for the testing > machinery and can not provide features/reporting as cleanly as the > above mentioned parametrized testing. I attached a full traceback. I agree with you on the yield based-parametrization. That's why I would like to move away from it and am experimenting with py.test. My secret goal is to implement something like Haskell's quickcheck. Generation of random test data is the easy part. The fun begins when you start to think about the different reporting needs a test might have in that case ('generated 10000 test cases, 97% pass, 14% trivial' for example). But first I have to migrate the current test suite... > > Is there a conditional flag that can tell me whether I'm > running under > > py.test? Then I could start experimenting with parametric > tests using > > funcargs, while keeping the test suite runnable with nose > at the moment. > > I still have a bug in the test suite, as I have tests > passing under nose > > that fail under py.test... > > There is no official way to detect if code is running within a test > session. > You might do something like: > > # contents of conftest.py > def pytest_configure(config): > import some_app_module > some_app_module._testing = True > > and then do a "hasattr(some_app_module, '_testing')" check or so. > However, most people don't consider it good practise to have > application > level code become aware if it's being tested or not. Instead > people use monkeypatching or dependency-injection to modify app > behaviour. My use case was actually to check in my test suite whether it's running under nose or under py.test. I think your (and Ronny's) suggestion to use the conftest mechanism provides a much cleaner solution. Thanks, Florian _______________________________________________________________________________________ Dialog Semiconductor GmbH Neue Str. 95 D-73230 Kirchheim Managing Director: Dr. Jalal Bagherli Chairman of the Supervisory Board: Gregorio Reyes Commercial register: Amtsgericht Stuttgart: HRB 231181 UST-ID-Nr. DE 811121668 Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. -------------- next part -------------- A non-text attachment was scrubbed... Name: traceback Type: application/octet-stream Size: 23326 bytes Desc: traceback Url : http://codespeak.net/pipermail/py-dev/attachments/20100902/c0877906/attachment-0001.obj From holger at merlinux.eu Thu Sep 2 11:27:22 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 2 Sep 2010 11:27:22 +0200 Subject: [py-dev] Advanced assert equal In-Reply-To: <20100816135154.GA24594@laurie.devork.be> References: <20100816002557.GA12335@laurie.devork.be> <1281958153.12940.5.camel@klappe2> <20100816135154.GA24594@laurie.devork.be> Message-ID: <20100902092722.GG1914@trillke.net> Hi Floris, sidenote: the original implementation was done by Armin Rigo and i am not much more accustomed to the assert-interpretation code than you are. The other guy having done bits there is Benjamin - still haven't got hold of him on this issue and your mail. But I discussed with Benjamin introducing a more general API that would have the AST-transformation call back into a generic pytest-hook if an assertion fails. So one could customize "hasattr(x, y)" or "x in y" or "x == y == z" etc. and all such representation code would move to the py/_plugin/pytest_assertion.py plugin. That being said going for just comparisons right now is fine, let's not have more general thoughts hold us up. On Mon, Aug 16, 2010 at 14:51 +0100, Floris Bruynooghe wrote: > On Mon, Aug 16, 2010 at 01:29:13PM +0200, Ronny Pfannschmidt wrote: > > On Mon, 2010-08-16 at 01:25 +0100, Floris Bruynooghe wrote: > > > The attached patch makes compare equal a special case and checks if > > > the two arguments to it are both a list, text or dict and tries to > > > generate a nicer explanation text for them. The patch is more like a > > > proof of concept then a final implementation, I may have done some > > > very strange or silly things as I'm not familiar with the code. It > > > would be great to get feedback, both on the general concept and the > > > actual implementation (particularly note the way I had to hack > > > _format_explanation() in assertion.py). > > > > I think it will be helpful to have some kind of hook to add more > > explain-functions > > Adding hooks should be possible, looking at all the .visit_*() > functions it would seem only one hook is required, unless separate > hooks for each rich compare operator are deemed useful. no, a single one for all comparisons sound fine. > The trickiest bit I think is how to produce multiline explanations. > _format_explanation() concatenates all newlines. Having only special > cases for \n{ and \n} which is used by .visit_Call() to force nested > and indented newlines. In the patch I added \n== for this but a more > general one is probably required, something like \n> or \n~ could work > I guess. This could be completely hidden from the hook however, by > returning a list for each line to be printed, the caller of the hook > would then join these up correctly so that _format_explanation() will > add newlines and indentation correctly. Makes sense to have the caller deal with concatentation. > A possible api for the hook > could be: > > def pytest_assert_compare(op, left, right, left_repr, right_repr): > """Customise compare > > Return None for no custom compare, otherwise return a list of > strings. The strings will be joined by newlines but any newlines > *in* a string will be escaped. > """ > pass > > I guess the reprs are not really necessary if there's an easy way to > make them. It's just that I used them in my original patch. Hum, couldn't custom representations just mean that there is no "history" of where the object comes from? The hook looks otherwise good to me. > Another option is to encapsulate the arguments into an object that > also knows how the builtin types and operators are compared, something > like: > > class CompareItem(object): > def __init__(self, op, left, right, ...): > self.op = op > self.left = left > self.right = right > ... > > def default(self): > if type(self.left) != type(self.right): > return None > if self.op == '==': > if isinstance(self.left, (list, tuple)): > return self.sequence_equal() > elif isinstance(self.left, basestring): > return self.string_equal() > ... > elif self.op == '!=': > ... > > def sequence_equal(self): > pass > > def string_equal(self): > pass > > ... > This would allow pytest_assert_compare() to use those methods as part > of the implementation. I think the other style is more sensible because delegation to "builtin representation styles" a) can happen via plugins and the plugin mechanism b) we could pass a "testrepr" or "builtinrepr" argument to the hook that helps to invoke helpful default machinery. (I guess you are aware that any pytest-hook implementation can always choose to accept less than the available arguments). > There's also the question of who should truncate large amounts of data > (e.g. screenfulls of diffs): the hook itself, the caller of the hook > or _format_explanation()? Probably one of the first two to get rid of > the memory usage as soon as possible. If a hook returns something we should (probably) not further do anything with it in _format_explanation(). And making truncation the repsonsibility of the hook makes sense i think. > > In particular, cause there are many more build-in types to manage, > > and i have at least 2 projects where custom compare-explain is helpfull > > > > another wishlist item i see is the rest of rich compare > > i.e. <, >, <=, >=, != > > Sure, all builtin types and operators should ideally be supported by > default as best as possible. I just started with some I wanted most. I am not sure about the general use cases, from my side: x == y x != y x in y are the interesting ones (with some of the objects being long lists, long strings etc.). so some hook for a "binary" relation makes sense, pytest_assert_binrepr(op) where op could be "==", "in" or "is" etc. Floris, i'd very much like to start using/having improved assertion representations. Happy to review patches or forks for inclusion. best, holger From issues-noreply at bitbucket.org Fri Sep 3 16:23:27 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Fri, 03 Sep 2010 14:23:27 -0000 Subject: [py-dev] New issue 116 in py-trunk: ImportMismatchError or ImportError encountered running py.test --doctest-modules with a package present Message-ID: --- you can reply above this line --- New issue 116: ImportMismatchError or ImportError encountered running py.test --doctest-modules with a package present http://bitbucket.org/hpk42/py-trunk/issue/116/importmismatcherror-or-importerror-encountered-running-pytest-doctest-modules-with-a-package Jason R. Coombs / jaraco on Fri, 3 Sep 2010 16:23:26 +0200: Description: To simply reproduce in py==1.3.3: {{{ mkdir package; touch package/__init__.py; py.test --doctest-modules }}} Results in the attached error messages (different on linux and Windows). running `py.test --doctest-modules package` seems to work around the issue. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From holger at merlinux.eu Fri Sep 3 17:30:34 2010 From: holger at merlinux.eu (holger krekel) Date: Fri, 3 Sep 2010 17:30:34 +0200 Subject: [py-dev] do you mind the issue-postings here? Message-ID: <20100903153034.GE32478@trillke.net> Hi all, am wondering: do you mind seeing new bitbucket issue creations here on the mailing list? If so i'll create a new mailing list pypy-issue or so and have things rather sent there. Just let me know. Personally i find it a bit unfortuante that the many closed/resolved issues are not notified to this list as well :) cheers, holger From issues-noreply at bitbucket.org Sat Sep 4 14:57:54 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sat, 04 Sep 2010 12:57:54 -0000 Subject: [py-dev] New issue 117 in py-trunk: setuptools errors bubble up in a unhelpfull way Message-ID: <4351b6401465d35da867a99981df9ade@bitbucket.org> --- you can reply above this line --- New issue 117: setuptools errors bubble up in a unhelpfull way http://bitbucket.org/hpk42/py-trunk/issue/117/setuptools-errors-bubble-up-in-a-unhelpfull Ronny Pfannschmidt / RonnyPfannschmidt on Sat, 4 Sep 2010 14:57:54 +0200: Description: i get the following trace because the setuptools errors just bubble up what i really needed to know is the EntryPoint as well, cause the origin was the still installed pytest_cov plugin {{{#!pytrace $ py.test inserting into sys.path: /home/ronny/Projects/py Traceback (most recent call last): File "/home/ronny/Projects/py/bin/py.test", line 3, in py.cmdline.pytest() File "/home/ronny/Projects/py/py/_test/cmdline.py", line 13, in main config.parse(args) File "/home/ronny/Projects/py/py/_test/config.py", line 95, in parse self._preparse(args) File "/home/ronny/Projects/py/py/_test/config.py", line 83, in _preparse self.pluginmanager.consider_setuptools_entrypoints() File "/home/ronny/Projects/py/py/_test/pluginmanager.py", line 104, in consider_setuptools_entrypoints plugin = ep.load() File "/home/ronny/Projects/distribute/pkg_resources.py", line 1953, in load if require: self.require(env, installer) File "/home/ronny/Projects/distribute/pkg_resources.py", line 1966, in require working_set.resolve(self.dist.requires(self.extras),env,installer)) File "/home/ronny/Projects/distribute/pkg_resources.py", line 552, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: pytest-xdist>=1.4 }}} Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From flub at devork.be Sun Sep 5 23:42:19 2010 From: flub at devork.be (Floris Bruynooghe) Date: Sun, 5 Sep 2010 22:42:19 +0100 Subject: [py-dev] Advanced assert equal In-Reply-To: <20100902092722.GG1914@trillke.net> References: <20100816002557.GA12335@laurie.devork.be> <1281958153.12940.5.camel@klappe2> <20100816135154.GA24594@laurie.devork.be> <20100902092722.GG1914@trillke.net> Message-ID: <20100905214219.GA31056@laurie.devork.be> Hello Holger On Thu, Sep 02, 2010 at 11:27:22AM +0200, holger krekel wrote: > would have the AST-transformation call back into a generic > pytest-hook if an assertion fails. So one could customize > "hasattr(x, y)" or "x in y" or "x == y == z" etc. and all > such representation code would move to the py/_plugin/pytest_assertion.py > plugin. That being said going for just comparisons right now > is fine, let's not have more general thoughts hold us up. I wouldn't want to make this more difficult or incompatible though, so I'd be interested in how you where thinking of doing this. I guess this would be exposing the various .visit_*() methods in _assertionnew.py in some way? If so I think there's also value in the more simple pytest_assert_compare(op, left, right) I'm proposing here (and others like "in", "is" etc) as they don't require having any AST knowledge to implement, at a cost of slightly less flexibility. > On Mon, Aug 16, 2010 at 14:51 +0100, Floris Bruynooghe wrote: > > A possible api for the hook > > could be: > > > > def pytest_assert_compare(op, left, right, left_repr, right_repr): > > """Customise compare > > > > Return None for no custom compare, otherwise return a list of > > strings. The strings will be joined by newlines but any newlines > > *in* a string will be escaped. > > """ > > pass > > > > I guess the reprs are not really necessary if there's an easy way to > > make them. It's just that I used them in my original patch. > > Hum, couldn't custom representations just mean that there is no > "history" of where the object comes from? > > The hook looks otherwise good to me. I've made this hook pytest_assert_compare(op, left, right) now, as I've found py.io.saferepr() which seems to do a good job. Not sure what you're referring too with the "history" comment. If you mean that as soon as a specialised hook is found the previous explanations (e.g. from Assert AST node) get lost I'd like to disagree. It seems reasonable for the new hooks to just provide a more detailed/specialised explanation of a particular part of the failure rather then replace the entire explanation. Otherwise you might also lose detail. > (I guess you are aware that any pytest-hook implementation can always > choose to accept less than the available arguments). I wasn't actually, neat. > > There's also the question of who should truncate large amounts of data > > (e.g. screenfulls of diffs): the hook itself, the caller of the hook > > or _format_explanation()? Probably one of the first two to get rid of > > the memory usage as soon as possible. > > If a hook returns something we should (probably) not further do anything > with it in _format_explanation(). And making truncation the repsonsibility > of the hook makes sense i think. ok > I am not sure about the general use cases, from my side: > > x == y > x != y > x in y > > are the interesting ones (with some of the objects being long > lists, long strings etc.). so some hook for a "binary" relation > makes sense, pytest_assert_binrepr(op) where op could be "==", > "in" or "is" etc. To me it seems more logical to add a separate hook for each .visit_*() method rather then put multiple together. But maybe that seems artificial from a user point of view? > Floris, i'd very much like to start using/having improved assertion > representations. Happy to review patches or forks for inclusion. I've attached a new patch in which I attempt to use the hook system and added a pytest_assert_comare(op, left, right) hook. I must admit I don't fully understand the plugin/hook system so hope I did it right [0]. Again I've not concentrated on the actual specific comparisons, rather would like to get a reasonable idea of how good the general approach is. If you like this version I can create a fork on bitbucket and start working on more/better hook implementations. Regards Floris [0] I assume that py.test.config.hook.pytest_assert_compare is the function to call and that it returns a list with the results of each such function found, with the first element being the most "specific" result. But I just figured that out using trial and error rather then understand the plugin system. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -------------- next part -------------- A non-text attachment was scrubbed... Name: pytest_assert.diff Type: text/x-diff Size: 8410 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20100905/f743f0e8/attachment.bin From holger at merlinux.eu Mon Sep 6 10:33:53 2010 From: holger at merlinux.eu (holger krekel) Date: Mon, 6 Sep 2010 10:33:53 +0200 Subject: [py-dev] Advanced assert equal In-Reply-To: <20100905214219.GA31056@laurie.devork.be> References: <20100816002557.GA12335@laurie.devork.be> <1281958153.12940.5.camel@klappe2> <20100816135154.GA24594@laurie.devork.be> <20100902092722.GG1914@trillke.net> <20100905214219.GA31056@laurie.devork.be> Message-ID: <20100906083353.GP32478@trillke.net> Hi Floris, On Sun, Sep 05, 2010 at 22:42 +0100, Floris Bruynooghe wrote: > Hello Holger > > On Thu, Sep 02, 2010 at 11:27:22AM +0200, holger krekel wrote: > > would have the AST-transformation call back into a generic > > pytest-hook if an assertion fails. So one could customize > > "hasattr(x, y)" or "x in y" or "x == y == z" etc. and all > > such representation code would move to the py/_plugin/pytest_assertion.py > > plugin. That being said going for just comparisons right now > > is fine, let's not have more general thoughts hold us up. > > I wouldn't want to make this more difficult or incompatible though, so > I'd be interested in how you where thinking of doing this. I guess > this would be exposing the various .visit_*() methods in > _assertionnew.py in some way? If so I think there's also value in the > more simple pytest_assert_compare(op, left, right) I'm proposing here > (and others like "in", "is" etc) as they don't require having any AST > knowledge to implement, at a cost of slightly less flexibility. Sure. The eventual callback that is to receive AST-nodes can remain internal and there is nothing from keeping us to offer both levels of hooks (the default impl for the low-level hook can just call the higher level ones). > > On Mon, Aug 16, 2010 at 14:51 +0100, Floris Bruynooghe wrote: > > > A possible api for the hook > > > could be: > > > > > > def pytest_assert_compare(op, left, right, left_repr, right_repr): > > > """Customise compare > > > > > > Return None for no custom compare, otherwise return a list of > > > strings. The strings will be joined by newlines but any newlines > > > *in* a string will be escaped. > > > """ > > > pass > > > > > > I guess the reprs are not really necessary if there's an easy way to > > > make them. It's just that I used them in my original patch. > > > > Hum, couldn't custom representations just mean that there is no > > "history" of where the object comes from? > > > > The hook looks otherwise good to me. > > I've made this hook pytest_assert_compare(op, left, right) now, as > I've found py.io.saferepr() which seems to do a good job. ok. > Not sure what you're referring too with the "history" comment. If you > mean that as soon as a specialised hook is found the previous > explanations (e.g. from Assert AST node) get lost I'd like to > disagree. It seems reasonable for the new hooks to just provide a > more detailed/specialised explanation of a particular part of the > failure rather then replace the entire explanation. Otherwise you > might also lose detail. Hum, ok. Let's see how this plays out with real failures. > > (I guess you are aware that any pytest-hook implementation can always > > choose to accept less than the available arguments). > > I wasn't actually, neat. > > > > There's also the question of who should truncate large amounts of data > > > (e.g. screenfulls of diffs): the hook itself, the caller of the hook > > > or _format_explanation()? Probably one of the first two to get rid of > > > the memory usage as soon as possible. > > > > If a hook returns something we should (probably) not further do anything > > with it in _format_explanation(). And making truncation the repsonsibility > > of the hook makes sense i think. > > ok > > > I am not sure about the general use cases, from my side: > > > > x == y > > x != y > > x in y > > > > are the interesting ones (with some of the objects being long > > lists, long strings etc.). so some hook for a "binary" relation > > makes sense, pytest_assert_binrepr(op) where op could be "==", > > "in" or "is" etc. > > To me it seems more logical to add a separate hook for each .visit_*() > method rather then put multiple together. But maybe that seems > artificial from a user point of view? I guess I prefer "pytest_assert_binop(op, val1, val2)" but keeping strictly to the visit relation also has merits. I guess my preference also comes from trying to avoid introducing too many hooks. > > Floris, i'd very much like to start using/having improved assertion > > representations. Happy to review patches or forks for inclusion. > > I've attached a new patch in which I attempt to use the hook system > and added a pytest_assert_comare(op, left, right) hook. I must admit > I don't fully understand the plugin/hook system so hope I did it > right [0]. Again I've not concentrated on the actual specific > comparisons, rather would like to get a reasonable idea of how good > the general approach is. Your hook implementation looks fine and [0] is correct. Please feel free to ask any questions regarding hook machinery here on the list. Are you aware of (the rather minimal) documentation here? http://codespeak.net/py/dist/test/customize.html#important-py-test-hooks > If you like this version I can create a fork on bitbucket and start > working on more/better hook implementations. Great, please do so. Two review notes regarding your patch already: * please try to avoid global imports in plugins, rather only import e.g. difflib/pprint where you actually use it. This is to try to keep interactive startup-time minimal, particularly wrt builtin plugins. * i suggest to put tests to testing/plugin/test_pytest_assertion.py (rather than testing/code/...) especially since the tested functionality is contained in the pytest_assertion.py plugin. For direct unit tests you may also directly do "from py._plugin.pytest_assertion import XYZ". best, holger > Regards > Floris > > > [0] I assume that py.test.config.hook.pytest_assert_compare is the > function to call and that it returns a list with the results of > each such function found, with the first element being the most > "specific" result. But I just figured that out using trial and > error rather then understand the plugin system. > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > diff --git a/py/_code/_assertionnew.py b/py/_code/_assertionnew.py > --- a/py/_code/_assertionnew.py > +++ b/py/_code/_assertionnew.py > @@ -162,10 +162,7 @@ class DebugInterpreter(ast.NodeVisitor): > def visit_Compare(self, comp): > left = comp.left > left_explanation, left_result = self.visit(left) > - got_result = False > for op, next_op in zip(comp.ops, comp.comparators): > - if got_result and not result: > - break > next_explanation, next_result = self.visit(next_op) > op_symbol = operator_map[op.__class__] > explanation = "%s %s %s" % (left_explanation, op_symbol, > @@ -177,9 +174,16 @@ class DebugInterpreter(ast.NodeVisitor): > __exprinfo_right=next_result) > except Exception: > raise Failure(explanation) > - else: > - got_result = True > + if not result: > + break > left_explanation, left_result = next_explanation, next_result > + hook_result = py.test.config.hook.pytest_assert_compare( > + op=op_symbol, left=left_result, right=next_result) > + if hook_result: > + for new_expl in hook_result: > + if result: > + explanation = '\n~'.join(new_expl) > + break > return explanation, result > > def visit_BoolOp(self, boolop): > diff --git a/py/_code/assertion.py b/py/_code/assertion.py > --- a/py/_code/assertion.py > +++ b/py/_code/assertion.py > @@ -5,12 +5,20 @@ BuiltinAssertionError = py.builtin.built > > > def _format_explanation(explanation): > - # uck! See CallFunc for where \n{ and \n} escape sequences are used > + """This formats an explanation > + > + Normally all embedded newlines are escaped, however there are > + three exceptions: \n{, \n} and \n~. The first two are intended > + cover nested explanations, see function and attribute explanations > + for examples (.visit_Call(), visit_Attribute()). The last one is > + for when one explanation needs to span multiple lines, e.g. when > + displaying diffs. > + """ > raw_lines = (explanation or '').split('\n') > - # escape newlines not followed by { and } > + # escape newlines not followed by {, } and ~ > lines = [raw_lines[0]] > for l in raw_lines[1:]: > - if l.startswith('{') or l.startswith('}'): > + if l.startswith('{') or l.startswith('}') or l.startswith('~'): > lines.append(l) > else: > lines[-1] += '\\n' + l > @@ -28,11 +36,14 @@ def _format_explanation(explanation): > stackcnt[-1] += 1 > stackcnt.append(0) > result.append(' +' + ' '*(len(stack)-1) + s + line[1:]) > - else: > + elif line.startswith('}'): > assert line.startswith('}') > stack.pop() > stackcnt.pop() > result[stack[-1]] += line[1:] > + else: > + assert line.startswith('~') > + result.append(' '*len(stack) + line[1:]) > assert len(stack) == 1 > return '\n'.join(result) > > diff --git a/py/_plugin/hookspec.py b/py/_plugin/hookspec.py > --- a/py/_plugin/hookspec.py > +++ b/py/_plugin/hookspec.py > @@ -124,6 +124,19 @@ def pytest_sessionfinish(session, exitst > """ whole test run finishes. """ > > # ------------------------------------------------------------------------- > +# hooks for customising the assert methods > +# ------------------------------------------------------------------------- > + > +def pytest_assert_compare(op, left, right): > + """Customise compare assertion > + > + Return None or an empty list for no custom compare, otherwise > + return a list of strings. The strings will be joined by newlines > + but any newlines *in* as string will be escaped. Note that all > + but the first line will be indented sligthly. > + """ > + > +# ------------------------------------------------------------------------- > # hooks for influencing reporting (invoked from pytest_terminal) > # ------------------------------------------------------------------------- > > diff --git a/py/_plugin/pytest_assertion.py b/py/_plugin/pytest_assertion.py > --- a/py/_plugin/pytest_assertion.py > +++ b/py/_plugin/pytest_assertion.py > @@ -1,3 +1,6 @@ > +import difflib > +import pprint > + > import py > import sys > > @@ -26,3 +29,49 @@ def warn_about_missing_assertion(): > else: > py.std.warnings.warn("Assertions are turned off!" > " (are you using python -O?)") > + > + > +def pytest_assert_compare(op, left, right): > + """Make a specialised explanation for comapare equal""" > + if op != '==' or type(left) != type(right): > + return None > + explanation = [] > + left_repr = py.io.saferepr(left, maxsize=30) > + right_repr = py.io.saferepr(right, maxsize=30) > + explanation += ['%s == %s' % (left_repr, right_repr)] > + issquence = lambda x: isinstance(x, (list, tuple)) > + istext = lambda x: isinstance(x, basestring) > + isdict = lambda x: isinstance(x, dict) > + if istext(left): > + explanation += [line.strip('\n') for line in > + difflib.ndiff(left.splitlines(), right.splitlines())] > + elif issquence(left): > + explanation += _compare_eq_sequence(left, right) > + elif isdict(left): > + explanation += _pprint_diff(left, right) > + else: > + return None # No specialised knowledge > + return explanation > + > + > +def _compare_eq_sequence(left, right): > + explanation = [] > + for i in xrange(min(len(left), len(right))): > + if left[i] != right[i]: > + explanation += ['First differing item %s: %s != %s' % > + (i, left[i], right[i])] > + break > + if len(left) > len(right): > + explanation += ['Left contains more items, ' > + 'first extra item: %s' % left[len(right)]] > + elif len(left) < len(right): > + explanation += ['Right contains more items, ' > + 'first extra item: %s' % right[len(right)]] > + return explanation + _pprint_diff(left, right) > + > + > +def _pprint_diff(left, right): > + """Make explanation using pprint and difflib""" > + return [line.strip('\n') for line in > + difflib.ndiff(pprint.pformat(left).splitlines(), > + pprint.pformat(right).splitlines())] > diff --git a/testing/code/test_assertionnew.py b/testing/code/test_assertionnew.py > new file mode 100644 > --- /dev/null > +++ b/testing/code/test_assertionnew.py > @@ -0,0 +1,74 @@ > +import sys > + > +import py > +from py._code._assertionnew import interpret > + > + > +def getframe(): > + """Return the frame of the caller as a py.code.Frame object""" > + return py.code.Frame(sys._getframe(1)) > + > + > +def setup_module(mod): > + py.code.patch_builtins(assertion=True, compile=False) > + > + > +def teardown_module(mod): > + py.code.unpatch_builtins(assertion=True, compile=False) > + > + > +def test_assert_simple(): > + # Simply test that this way of testing works > + a = 0 > + b = 1 > + r = interpret('assert a == b', getframe()) > + assert r == 'assert 0 == 1' > + > + > +def test_assert_list(): > + r = interpret('assert [0, 1] == [0, 2]', getframe()) > + msg = ('assert [0, 1] == [0, 2]\n' > + ' First differing item 1: 1 != 2\n' > + ' - [0, 1]\n' > + ' ? ^\n' > + ' + [0, 2]\n' > + ' ? ^') > + print r > + assert r == msg > + > + > +def test_assert_string(): > + r = interpret('assert "foo and bar" == "foo or bar"', getframe()) > + msg = ("assert 'foo and bar' == 'foo or bar'\n" > + " - foo and bar\n" > + " ? ^^^\n" > + " + foo or bar\n" > + " ? ^^") > + print r > + assert r == msg > + > + > +def test_assert_multiline_string(): > + a = 'foo\nand bar\nbaz' > + b = 'foo\nor bar\nbaz' > + r = interpret('assert a == b', getframe()) > + msg = ("assert 'foo\\nand bar\\nbaz' == 'foo\\nor bar\\nbaz'\n" > + ' foo\n' > + ' - and bar\n' > + ' + or bar\n' > + ' baz') > + print r > + assert r == msg > + > + > +def test_assert_dict(): > + a = {'a': 0, 'b': 1} > + b = {'a': 0, 'c': 2} > + r = interpret('assert a == b', getframe()) > + msg = ("assert {'a': 0, 'b': 1} == {'a': 0, 'c': 2}\n" > + " - {'a': 0, 'b': 1}\n" > + " ? ^ ^\n" > + " + {'a': 0, 'c': 2}\n" > + " ? ^ ^") > + print r > + assert r == msg > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev -- From issues-noreply at bitbucket.org Tue Sep 7 17:02:27 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Tue, 07 Sep 2010 15:02:27 -0000 Subject: [py-dev] New issue 118 in py-trunk: native traceback option Message-ID: --- you can reply above this line --- New issue 118: native traceback option http://bitbucket.org/hpk42/py-trunk/issue/118/native-traceback-option nikow on Tue, 7 Sep 2010 17:02:27 +0200: Description: I'm using Eclipse with PyDev and when running unittest this allows me to click on the traceback information to directly jump to the code. For py.test when called from the IDE this does not work, since apparently PyDev relies on the standard traceback format to make it clickable. Therefore it would be great if a --tb option was added to display tracebacks in the native formatting. For now I fixed this by inserting the following code in collect.py in line 177: {{{ import traceback tb_strs = traceback.format_tb(excinfo._excinfo[2]) i = 0 while not tb_strs[i].endswith(" testfunction(**funcargs)\n"): i += 1 tb_strs = tb_strs[i+1:] return "\n" + "".join(tb_strs) + "\n" }}} On a side note: I'm currently use {{{py.test.cmdline.main(...)}}} to run py.test from inside the IDE. Maybe one could add some "offical" API to call py.test in this way. Thanks. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From flub at devork.be Wed Sep 8 23:38:02 2010 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 8 Sep 2010 22:38:02 +0100 Subject: [py-dev] Advanced assert equal In-Reply-To: <20100906083353.GP32478@trillke.net> References: <20100816002557.GA12335@laurie.devork.be> <1281958153.12940.5.camel@klappe2> <20100816135154.GA24594@laurie.devork.be> <20100902092722.GG1914@trillke.net> <20100905214219.GA31056@laurie.devork.be> <20100906083353.GP32478@trillke.net> Message-ID: <20100908213802.GA27981@laurie.devork.be> Hello On Mon, Sep 06, 2010 at 10:33:53AM +0200, holger krekel wrote: > On Sun, Sep 05, 2010 at 22:42 +0100, Floris Bruynooghe wrote: > > On Thu, Sep 02, 2010 at 11:27:22AM +0200, holger krekel wrote: > > > On Mon, Aug 16, 2010 at 14:51 +0100, Floris Bruynooghe wrote: > > > Hum, couldn't custom representations just mean that there is no > > > "history" of where the object comes from? [...] > > Not sure what you're referring too with the "history" comment. If you > > mean that as soon as a specialised hook is found the previous > > explanations (e.g. from Assert AST node) get lost I'd like to > > disagree. It seems reasonable for the new hooks to just provide a > > more detailed/specialised explanation of a particular part of the > > failure rather then replace the entire explanation. Otherwise you > > might also lose detail. > > Hum, ok. Let's see how this plays out with real failures. Agreed, I don't feel too strongly about it but would like to see how it works out as it is now. > > To me it seems more logical to add a separate hook for each .visit_*() > > method rather then put multiple together. But maybe that seems > > artificial from a user point of view? > > I guess I prefer "pytest_assert_binop(op, val1, val2)" > but keeping strictly to the visit relation also has merits. > I guess my preference also comes from trying to avoid introducing > too many hooks. Again I don't feel too strongly, you've got more say on the hook API then me so if you want I can rename it and we can see how it looks once there are more implementations for e.g. "in", "is" etc. > > If you like this version I can create a fork on bitbucket and start > > working on more/better hook implementations. > > Great, please do so. Two review notes regarding your patch already: > > * please try to avoid global imports in plugins, rather only import > e.g. difflib/pprint where you actually use it. This is to try to > keep interactive startup-time minimal, particularly wrt builtin plugins. > > * i suggest to put tests to testing/plugin/test_pytest_assertion.py > (rather than testing/code/...) especially since the tested functionality > is contained in the pytest_assertion.py plugin. For direct unit tests > you may also directly do "from py._plugin.pytest_assertion import XYZ". As you've probably noticed I've made a fork at http://bitbucket.org/flub/py-trunk-assert. I've addressed these two points in it already, or so I hope. I can't figure out how to properly test the plugin however, it either feels too brittle or too loose. So any hints on how to test that sort of thing would be welcome. Other then that I need to get on with implementing more and better default behaviour, at least cover everything unittest2 does. Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From holger at merlinux.eu Thu Sep 9 11:07:44 2010 From: holger at merlinux.eu (holger krekel) Date: Thu, 9 Sep 2010 11:07:44 +0200 Subject: [py-dev] Advanced assert equal In-Reply-To: <20100908213802.GA27981@laurie.devork.be> References: <20100816002557.GA12335@laurie.devork.be> <1281958153.12940.5.camel@klappe2> <20100816135154.GA24594@laurie.devork.be> <20100902092722.GG1914@trillke.net> <20100905214219.GA31056@laurie.devork.be> <20100906083353.GP32478@trillke.net> <20100908213802.GA27981@laurie.devork.be> Message-ID: <20100909090744.GX32478@trillke.net> On Wed, Sep 08, 2010 at 22:38 +0100, Floris Bruynooghe wrote: > As you've probably noticed I've made a fork at > http://bitbucket.org/flub/py-trunk-assert. I've addressed these two > points in it already, or so I hope. I can't figure out how to > properly test the plugin however, it either feels too brittle or too > loose. So any hints on how to test that sort of thing would be > welcome. The tests you added in http://bitbucket.org/flub/py-trunk-assert/src/c8e85f1f4adb/testing/plugin/test_pytest_assertion.py look fine to me. You could check for a bit more detail on some selected examples but the main thing is to make sure that nothing blows up. Regarding the tests in http://bitbucket.org/flub/py-trunk-assert/src/c8e85f1f4adb/testing/code/test_assertionnew.py i'd rather move them to the above plugin test module. py/code is completely independent from py.test. Speaking of it, in _assertionew.py your very call to py.test.config.pytest_assert_compare() is problematic. ``py.test.config`` is a global access path that is never used internally. Not too far off i'd like to get rid of ``py.test.config`` alltogether or rather move it to a "pytest_compat" plugin which maintains some older APIs/behaviours. For your branch, it means that the pytest_assertion plugin needs to parametrize the assertion-machinery with a config/hook object. Maybe for now, we can just do something like: def pytest_configure(config): ... py.builtin.builtins.AssertionError._pytesthook = config.hook and check for and call through this attribute from _assertionnew.py. This means that if one uses py/code without py.test then the latter will be not be initialized/touched at all (accessing py.test.config triggers default plugin loading and basic initialization). > Other then that I need to get on with implementing more and better > default behaviour, at least cover everything unittest2 does. Great, thanks. This looks all quite good. Looking forward to use it myself soon :) best, holger From issues-noreply at bitbucket.org Tue Sep 14 13:49:29 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Tue, 14 Sep 2010 11:49:29 -0000 Subject: [py-dev] New issue 119 in py-trunk: Fail to impot __init__.py - INTERNALERROR> self = Message-ID: --- you can reply above this line --- New issue 119: Fail to impot __init__.py - INTERNALERROR> self = http://bitbucket.org/hpk42/py-trunk/issue/119/fail-to-impot-__init__py-internalerror sorin on Tue, 14 Sep 2010 13:49:29 +0200: Description: For some reason py.test fails on any __init__.py file. How to reproduce: * create an empty __init__.py * execute py.test --collectonly INTERNALERROR> self = INTERNALERROR> colitems = [] INTERNALERROR> INTERNALERROR> def main(self, colitems): INTERNALERROR> """ main loop for running tests. """ INTERNALERROR> self.shouldstop = False INTERNALERROR> self.sessionstarts() INTERNALERROR> exitstatus = EXIT_OK INTERNALERROR> try: INTERNALERROR> > self._mainloop(colitems) INTERNALERROR> INTERNALERROR> colitems = [] INTERNALERROR> exitstatus = 0 INTERNALERROR> self = INTERNALERROR> INTERNALERROR> C:\lib\Python26.x86\lib\site-packages\py-1.3.3-py2.6.egg\py\_test\session.py:113: INTERNALERROR> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ... Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Tue Sep 14 15:20:15 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Tue, 14 Sep 2010 13:20:15 -0000 Subject: [py-dev] New issue 120 in py-trunk: Add collect_include option to complement collect_ignore option. Message-ID: --- you can reply above this line --- New issue 120: Add collect_include option to complement collect_ignore option. http://bitbucket.org/hpk42/py-trunk/issue/120/add-collect_include-option-to-complement-collect_ignore sorin on Tue, 14 Sep 2010 15:20:15 +0200: Description: On big/huge project people may want to scan only some directories, and in order to obtain this the current `collect_ignore` list is not enough. Adding tons of directories to `collect_ignore` may not be the best practice instead of just adding the locations you want to be scanned. I would like to propose the addition of `collect_include` option that would allow only the files matching the patterns from it to be scanned. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From holger at merlinux.eu Tue Sep 14 17:34:33 2010 From: holger at merlinux.eu (holger krekel) Date: Tue, 14 Sep 2010 17:34:33 +0200 Subject: [py-dev] pylib/py.test 1.3.4: fixes and new native traceback option Message-ID: <20100914153433.GM32478@trillke.net> pylib/py.test 1.3.4 is a minor maintenance release mostly containing bug fixes and a new "--tb=native" traceback option to show "normal" Python standard tracebacks instead of the py.test enhanced tracebacks. See below for more change info and http://pytest.org for more general information on features and configuration of the testing tool. Thanks to the issue reporters and generally to Ronny Pfannschmidt for help. cheers, holger krekel Changes between 1.3.3 and 1.3.4 ================================================== - fix issue111: improve install documentation for windows - fix issue119: fix custom collectability of __init__.py as a module - fix issue116: --doctestmodules work with __init__.py files as well - fix issue115: unify internal exception passthrough/catching/GeneratorExit - fix issue118: new --tb=native for presenting cpython-standard exceptions -- From flub at devork.be Wed Sep 22 02:11:27 2010 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 22 Sep 2010 01:11:27 +0100 Subject: [py-dev] Advanced assert equal In-Reply-To: <20100909090744.GX32478@trillke.net> References: <20100816002557.GA12335@laurie.devork.be> <1281958153.12940.5.camel@klappe2> <20100816135154.GA24594@laurie.devork.be> <20100902092722.GG1914@trillke.net> <20100905214219.GA31056@laurie.devork.be> <20100906083353.GP32478@trillke.net> <20100908213802.GA27981@laurie.devork.be> <20100909090744.GX32478@trillke.net> Message-ID: Hi Holger I've updated my repo with the following changes: * Don't use py.test.config, using Holger's suggestion of an attribute on AssertionError * Renamed pytest_assert_compare to pytest_assert_binrepr * Moved all tests to testing/plugin/test_pytest_assertion.py * Implemented the default hook to pretty much mirror unittest2's behaviour. * Added examples in doc/examples/assertion/failure_demo.py - I found this easier to work with then the actual tests I guess the main thing now is to fine-tune the default reporting for various cases. I'm fairly tempted not to try and predict too much in this area and rather wait to tune these till they come up. Related to this you said you'd like to see "x in y" and "x != y" for some types. Could you be more specific as I can't think of what you'd like to do with "in" or "!=", I'm probably lacking creativity right now... I'm happy to hear feedback anyone might have, I've probably still missed things. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From holger at merlinux.eu Wed Sep 22 11:55:54 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 22 Sep 2010 11:55:54 +0200 Subject: [py-dev] Advanced assert equal In-Reply-To: References: <20100816002557.GA12335@laurie.devork.be> <1281958153.12940.5.camel@klappe2> <20100816135154.GA24594@laurie.devork.be> <20100902092722.GG1914@trillke.net> <20100905214219.GA31056@laurie.devork.be> <20100906083353.GP32478@trillke.net> <20100908213802.GA27981@laurie.devork.be> <20100909090744.GX32478@trillke.net> Message-ID: <20100922095554.GH15851@trillke.net> hi Floris, On Wed, Sep 22, 2010 at 01:11 +0100, Floris Bruynooghe wrote: > Hi Holger > > I've updated my repo with the following changes: > > * Don't use py.test.config, using Holger's suggestion of an attribute > on AssertionError > * Renamed pytest_assert_compare to pytest_assert_binrepr > * Moved all tests to testing/plugin/test_pytest_assertion.py > * Implemented the default hook to pretty much mirror unittest2's behaviour. > * Added examples in doc/examples/assertion/failure_demo.py - I found > this easier to work with then the actual tests > > > I guess the main thing now is to fine-tune the default reporting for > various cases. I'm fairly tempted not to try and predict too much in > this area and rather wait to tune these till they come up. Yes, this makes sense. I am eager to merge, a few things: * could you merge current py-trunk? * could you run tests on python3? * could you maybe look into the two failures i attached as test_bugs.py? (feel free to hang out/ask on #pylib - i should be there a lot this week and today). > Related to this you said you'd like to see "x in y" and "x != y" for > some types. Could you be more specific as I can't think of what you'd > like to do with "in" or "!=", I'm probably lacking creativity right > now... Let's see when i or someone else actually comes up with a concrete case :) > I'm happy to hear feedback anyone might have, I've probably still missed things. Thanks already for your work, great additions. best, holger > > Regards > Floris > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: test_bugs.py Type: text/x-python Size: 235 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20100922/4e9b4391/attachment.py From issues-noreply at bitbucket.org Mon Sep 27 11:35:10 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Mon, 27 Sep 2010 09:35:10 -0000 Subject: [py-dev] New issue 121 in py-trunk: py.test seems gather tests from upper directories Message-ID: <8ae1cb022651e3d466d763c5550d3537@bitbucket.org> --- you can reply above this line --- New issue 121: py.test seems gather tests from upper directories http://bitbucket.org/hpk42/py-trunk/issue/121/pytest-seems-gather-tests-from-upper bluebird75 on Mon, 27 Sep 2010 11:35:10 +0200: Description: I don't know what's wrong with my setup, but since I upgraded py.test , it no longer restrict itself to the current directory and subdirectories, it looks up for other directories. {{{ #!bash hilippe at pc-philippe /cygdrive/d/work/elc-dev $ ls -d elc* elc-memory/ elc-py26/ elc-work-fh1/ elc2/ elc-merge-linkchecker/ elc-ref/ elc1/ elc3/ Philippe at pc-philippe /cygdrive/d/work/elc-dev $ cd elc1 Philippe at pc-philippe /cygdrive/d/work/elc-dev/elc1 $ py.test 2010-09-27 11:30:59,592 5404 INFO elc.ElcLogger init_logging_local done C:\Python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_plugin\pytest_default.py:57: DeprecationWarning: was found in a conftest.py file, use pytest_collect hooks instead. (since version >1.1) Directory = parent.config._getcollectclass('Directory', path) Traceback (most recent call last): File "c:\Python26\Scripts\py.test-script.py", line 8, in load_entry_point('py==1.3.4', 'console_scripts', 'py.test')() File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_cmdline\pytest.py", line 5, in main raise SystemExit(py.test.cmdline.main(args)) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\cmdline.py", line 16, in main colitems = config.getinitialnodes() File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\config.py", line 158, in getinitialnodes return [self.getnode(arg) for arg in self.args] File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\config.py", line 173, in getnode return self._rootcol.getbynames(names) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\collect.py", line 388, in getbynames for x in current._memocollect(): File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\collect.py", line 230, in _memocollect return self._memoizedcall('_collected', self.collect) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\collect.py", line 104, in _memoizedcall res = function() File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\collect.py", line 300, in collect res = self.consider(path) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\collect.py", line 309, in consider if self.ihook.pytest_ignore_collect(path=path, config=self.config): File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\collect.py", line 21, in call_matching_hooks return hookmethod.pcall(plugins, **kwargs) File "C:\Python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\pluginmanager.py", line 354, in pcall return self.hookrelay._performcall(self.name, mc) File "C:\Python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\pluginmanager.py", line 335, in _performcall return multicall.execute() File "C:\Python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\pluginmanager.py", line 244, in execute res = method(**kwargs) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_plugin\pytest_default.py", line 32, in pytest_ignore_collect ignore_paths = config.getconftest_pathlist("collect_ignore", path=path) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\config.py", line 195, in getconftest_pathlist mod, relroots = self._conftest.rget_with_confmod(name, path) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\conftesthandle.py", line 88, in rget_with_confmod modules = self.getconftestmodules(path) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\conftesthandle.py", line 72, in getconftestmodules clist.append(self.importconftest(conftestpath)) File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_test\conftesthandle.py", line 108, in importconftest mod = conftestpath.pyimport() File "c:\python26\lib\site-packages\py-1.3.4-py2.6.egg\py\_path\local.py", line 540, in pyimport raise self.ImportMismatchError(modname, modfile, self) py._path.local.ImportMismatchError: ('conftest', 'd:\\work\\elc-dev\\Copy of git-linkchecker\\conftest.py', local('d:\\work\\elc-dev\\elc-memory\\conftest.py')) Philippe at pc-philippe /cygdrive/d/work/elc-dev/elc1 $ }}} The errors reported below belong to other directories than elc1. I have a conftest.py in elc1: {{{ #!python Philippe at pc-philippe /cygdrive/d/work/elc-dev/elc1 $ cat conftest.py # this module is loaded by py.test before running the tests import fix_path import elcloginit import tests.httpd_utils as httpd_utils from tests.setupDbTestEnv import SetupDbTestEnv, envDict collect_ignore = [ 'elc_linkchecker/linkchecker/' ] DB_TEST_ENV = None def pytest_namespace(): global DB_TEST_ENV DB_TEST_ENV = SetupDbTestEnv() envDict[ 'dbTestEnv' ] = DB_TEST_ENV return envDict def pytest_sessionstart( session ): # print 'pytest_sessionstart' DB_TEST_ENV.setup() def pytest_sessionfinish( session, exitstatus ): # print 'pytest_sessionfinish' DB_TEST_ENV.teardown() pass }}} Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Tue Sep 28 16:33:23 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Tue, 28 Sep 2010 14:33:23 -0000 Subject: [py-dev] New issue 122 in py-trunk: store/reuse the state of a last run from a previous session dir Message-ID: <6b06d9807e28da196730f1d928f3c92f@bitbucket.org> --- you can reply above this line --- New issue 122: store/reuse the state of a last run from a previous session dir http://bitbucket.org/hpk42/py-trunk/issue/122/store-reuse-the-state-of-a-last-run-from-a-previous-session Ronny Pfannschmidt / RonnyPfannschmidt on Tue, 28 Sep 2010 16:33:23 +0200: Description: taking failures/not yet executed items from the last session dir could help in various cases to prevent tests from rerunning Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From flub at devork.be Wed Sep 29 01:12:53 2010 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 29 Sep 2010 00:12:53 +0100 Subject: [py-dev] controlling assertions and difflib Message-ID: Hi As Holger pointed out the following test hangs py.test in my assertion clone, it triggers a bug in difflib: def test_hang_in_diff(): x = "1\n" * 1000 + "abc" + "2\n" * 1000 y = "1\n" * 1000 + "def" + "2\n" * 1000 assert x == y It seems difflib can not deal with the 1000 identical trailing items. It fails with a TypeError somewhere very deep in a recursion or, when consuming the generator inside a list comprehension, just completely hangs. Also before failing it considers all the 2s as different too. Rather then debugging difflib (there are several possible bugs on bugs.python.org which might relate to this) I've come up with some code that does produce this instead: ______________________________ test_hang_in_diff _______________________________ /tmp/sandbox/test_bugs.py:4: in test_hang_in_diff > assert x == y E assert '1\n1\n1\n1\n...n2\n2\n2\n2\n' == '1\n1\n1\n1\n...n2\n2\n2\n2\n' E Skipping 1990 identical leading characters in diff E Skipping 1991 identical trailing characters in diff E 1 E 1 E 1 E 1 E 1 E - abc2 E + def2 E 2 E 2 E 2 E 2 Another solution is to use context_diff() which does not have this problem, but for some reason also considers all the trailing 2s to be different. Additionally context diff also doesn't provide the nice markers for differences inside a line which might be problematic as there's no guarantee there will be nice line endings in the input. In general I was already thinking of cutting off similar prefixes and suffixes before using ndiff, so this doesn't seem that bad to me. Do others think this is acceptable? This whole issue made me wonder if it should be possible to disable the pytest_assert_binrepr hook. It is probably sufficient to add an option which can be checked right at the start of the builtin pytest_assert_binrepr hook which will just return None or [] right away. But what is the best way to access the config setting from there? Is it fine to use py.test.config or should the setting be piggy-backed on some global again (e.g. change the current py.builtin.builtins.AssertionError._pytesthook into a ._pytestconfig)? Or maybe there's a more elegant solution for this that I'm unaware of? Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From holger at merlinux.eu Wed Sep 29 15:28:18 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 29 Sep 2010 15:28:18 +0200 Subject: [py-dev] controlling assertions and difflib In-Reply-To: References: Message-ID: <20100929132818.GK20695@trillke.net> Hey Floris, all, On Wed, Sep 29, 2010 at 00:12 +0100, Floris Bruynooghe wrote: > As Holger pointed out the following test hangs py.test in my assertion > clone, it triggers a bug in difflib: > > def test_hang_in_diff(): > x = "1\n" * 1000 + "abc" + "2\n" * 1000 > y = "1\n" * 1000 + "def" + "2\n" * 1000 > assert x == y > > It seems difflib can not deal with the 1000 identical trailing items. > > It fails with a TypeError somewhere very deep in a recursion or, when > consuming the generator inside a list comprehension, just completely > hangs. Also before failing it considers all the 2s as different too. > Rather then debugging difflib (there are several possible bugs on > bugs.python.org which might relate to this) I've come up with some > code that does produce this instead: > > ______________________________ test_hang_in_diff _______________________________ > /tmp/sandbox/test_bugs.py:4: in test_hang_in_diff > > assert x == y > E assert '1\n1\n1\n1\n...n2\n2\n2\n2\n' == '1\n1\n1\n1\n...n2\n2\n2\n2\n' > E Skipping 1990 identical leading characters in diff > E Skipping 1991 identical trailing characters in diff > E 1 > E 1 > E 1 > E 1 > E 1 > E - abc2 > E + def2 > E 2 > E 2 > E 2 > E 2 looks good to me! > Another solution is to use context_diff() which does not have this > problem, but for some reason also considers all the trailing 2s to be > different. Additionally context diff also doesn't provide the nice > markers for differences inside a line which might be problematic as > there's no guarantee there will be nice line endings in the input. > > In general I was already thinking of cutting off similar prefixes and > suffixes before using ndiff, so this doesn't seem that bad to me. Do > others think this is acceptable? I find it acceptable. I guess we need to see how it works in RL projects. Btw, I find it hard to guess how many people actually read this ML, despite there being some >130 subscribers. But we'll get issue reports when things go bad i guess :) > This whole issue made me wonder if it should be possible to disable > the pytest_assert_binrepr hook. We could do a general "--assertmode=(choice)" with e.g.: 0: (no) don't do any assert reinterp (like --no-assert now) 1: (basic) do basic reinterpreation 2: (advanced) do basic reinterpretation + customizing hooks and default to 2. > It is probably sufficient to add an > option which can be checked right at the start of the builtin > pytest_assert_binrepr hook which will just return None or [] right > away. But what is the best way to access the config setting from > there? Is it fine to use py.test.config or should the setting be > piggy-backed on some global again (e.g. change the current > py.builtin.builtins.AssertionError._pytesthook into a ._pytestconfig)? > Or maybe there's a more elegant solution for this that I'm unaware > of? I think there is an elegant solution. Instead of using "hook" in py/code/ we use a generic "customize" function that is to be called. In pytest_assertion.py's pytest_configure we write that function such that it calls pytest_assert_binrepr(config, ...) hope that makes sense. If in doubt leave it to me and just use py.test.config. I also want to introduce an "ini" style file for py.test, btw. hopefully real soon now. best, holger From issues-noreply at bitbucket.org Wed Sep 29 15:52:19 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Wed, 29 Sep 2010 13:52:19 -0000 Subject: [py-dev] New issue 123 in py-trunk: new invocation: "python -m py.test" Message-ID: <28eb92790aa9b9656133c9641ee1f4a1@bitbucket.org> --- you can reply above this line --- New issue 123: new invocation: "python -m py.test" http://bitbucket.org/hpk42/py-trunk/issue/123/new-invocation-python-m-pytest holger krekel / hpk42 on Wed, 29 Sep 2010 15:52:19 +0200: Description: As with unittest2 and other tools it'd be nice to be able to call py.test without invoking an extra command line tool. For example, on Windows/Jython setuptools/distutils does not even create working command line tool scripts (known issue). Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Thu Sep 30 16:33:58 2010 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Thu, 30 Sep 2010 14:33:58 -0000 Subject: [py-dev] New issue 124 in py-trunk: disabling capture makes the capfd funcarg break py.test Message-ID: --- you can reply above this line --- New issue 124: disabling capture makes the capfd funcarg break py.test http://bitbucket.org/hpk42/py-trunk/issue/124/disabling-capture-makes-the-capfd-funcarg-break Ronny Pfannschmidt / RonnyPfannschmidt on Thu, 30 Sep 2010 16:33:58 +0200: Description: the bottom line is getting a invalid fd in the terminalwriter {{{ #!text $ py.test -v testing/ -k test_stdouterrin_setnull inserting into sys.path: /home/ronny/Projects/py ==================================================================== test session starts ==================================================================== platform linux2 -- Python 2.6.5 -- pytest-1.4.0a1 -- /usr/bin/python gateway test setup scope: session execnet: /home/ronny/Projects/execnet/execnet/__init__.pyc -- 1.0.9.dev0 test path 1: testing/ testing/test_basics.py:145: test_stdouterrin_setnull PASSED ==================================================== 324 tests deselected by 'test_stdouterrin_setnull' ===================================================== ========================================================= 1 passed, 324 deselected in 0.27 seconds ========================================================== 16:28:15 | ~/Projects/execnet $ py.test -v testing/ -ks test_stdouterrin_setnull inserting into sys.path: /home/ronny/Projects/py ==================================================================== test session starts ==================================================================== platform linux2 -- Python 2.6.5 -- pytest-1.4.0a1 -- /usr/bin/python gateway test setup scope: session execnet: /home/ronny/Projects/execnet/execnet/__init__.pyc -- 1.0.9.dev0 ERROR: file not found: /home/ronny/Projects/execnet/test_stdouterrin_setnull 16:28:20 | ~/Projects/execnet $ py.test -vs -k test_stdouterrin_setnull inserting into sys.path: /home/ronny/Projects/py ==================================================================== test session starts ==================================================================== platform linux2 -- Python 2.6.5 -- pytest-1.4.0a1 -- /usr/bin/python gateway test setup scope: session execnet: /home/ronny/Projects/execnet/execnet/__init__.pyc -- 1.0.9.dev0 test path 1: /home/ronny/Projects/execnet testing/test_basics.py:145: test_stdouterrin_setnull Traceback (most recent call last): File "/home/ronny/Projects/py/bin/py.test", line 3, in py.cmdline.pytest() File "/home/ronny/Projects/py/py/_cmdline/pytest.py", line 5, in main raise SystemExit(py.test.cmdline.main(args)) File "/home/ronny/Projects/py/py/_test/session.py", line 21, in main exitstatus = config.hook.pytest_cmdline_main(config=config) File "/home/ronny/Projects/py/py/_test/pluginmanager.py", line 352, in __call__ return self.hookrelay._performcall(self.name, mc) File "/home/ronny/Projects/py/py/_test/pluginmanager.py", line 338, in _performcall return multicall.execute() File "/home/ronny/Projects/py/py/_test/pluginmanager.py", line 244, in execute res = method(**kwargs) File "/home/ronny/Projects/py/py/_plugin/pytest_default.py", line 8, in pytest_cmdline_main return Session(config).main() File "/home/ronny/Projects/py/py/_test/session.py", line 77, in main self.config.pluginmanager.notify_exception(excinfo) File "/home/ronny/Projects/py/py/_test/pluginmanager.py", line 166, in notify_exception return self.hook.pytest_internalerror(excrepr=excrepr) File "/home/ronny/Projects/py/py/_test/pluginmanager.py", line 352, in __call__ return self.hookrelay._performcall(self.name, mc) File "/home/ronny/Projects/py/py/_test/pluginmanager.py", line 338, in _performcall return multicall.execute() File "/home/ronny/Projects/py/py/_test/pluginmanager.py", line 244, in execute res = method(**kwargs) File "/home/ronny/Projects/py/py/_plugin/pytest_terminal.py", line 120, in pytest_internalerror self.write_line("INTERNALERROR> " + line) File "/home/ronny/Projects/py/py/_plugin/pytest_terminal.py", line 112, in write_line self._tw.line(line, **markup) File "/home/ronny/Projects/py/py/_io/terminalwriter.py", line 182, in line self.write(s, **kw) File "/home/ronny/Projects/py/py/_io/terminalwriter.py", line 168, in write self._file.flush() IOError: [Errno 9] Bad file descriptor Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.