From issues-reply at bitbucket.org Thu Nov 1 15:32:27 2012 From: issues-reply at bitbucket.org (Stefan Scherfke) Date: Thu, 01 Nov 2012 14:32:27 -0000 Subject: [py-dev] =?utf-8?q?=5Bhpk42/pytest=5D_mock=2Epatch-Decorator_and_?= =?utf-8?q?test_fixtures_don=E2=80=99t_work_together_=28issue_=23217=29?= Message-ID: --- you can reply above this line --- New issue 217: mock.patch-Decorator and test fixtures don?t work together https://bitbucket.org/hpk42/pytest/issue/217/mockpatch-decorator-and-test-fixtures-don Stefan Scherfke: This: ``` #!python import mock @mock.patch('sys.exit') def test_spam(exit_mock, tmpdir): assert isinstance(exit_mock. mock.Mock) ``` does not work and fails like this: ``` #!bash __________________________________ test_spam ___________________________________ @wraps(func) def patched(*args, **keywargs): # don't use a with here (backwards compatability with Python 2.4) extra_args = [] entered_patchers = [] # can't use try...except...finally because of Python 2.4 # compatibility exc_info = tuple() try: try: for patching in patched.patchings: arg = patching.__enter__() entered_patchers.append(patching) if patching.attribute_name is not None: keywargs.update(arg) elif patching.new is DEFAULT: extra_args.append(arg) args += tuple(extra_args) > return func(*args, **keywargs) E TypeError: test_spam() takes exactly 2 arguments (1 given) /Users/stefan/.virtualenvs/simpy/lib/python3.2/site-packages/mock.py:1190: TypeError ``` I?m not sure whether pytest or mock is to blame so I posted this on each issue tracker. 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 jiffyclub at gmail.com Fri Nov 2 15:12:34 2012 From: jiffyclub at gmail.com (Matt Davis) Date: Fri, 2 Nov 2012 10:12:34 -0400 Subject: [py-dev] 2.3.3 Release Date Message-ID: Hi all, I work on the AstroPy project (http://astropy.org). We bundle py.test with our distribution and for an upcoming release we need the fixture features in py.test 2.3, but we also need the bug fix from https://bitbucket.org/hpk42/pytest/issue/213/issue-with-numpy-arrays-andthat will be in 2.3.3. Is there any estimate for when 2.3.3 will be released? We are hoping to do an AstroPy release in the next couple of weeks. Thank you, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Fri Nov 2 16:22:59 2012 From: holger at merlinux.eu (holger krekel) Date: Fri, 2 Nov 2012 15:22:59 +0000 Subject: [py-dev] 2.3.3 Release Date In-Reply-To: References: Message-ID: <20121102152259.GV27773@merlinux.eu> Hi Matt, On Fri, Nov 02, 2012 at 10:12 -0400, Matt Davis wrote: > Hi all, > > I work on the AstroPy project (http://astropy.org). We bundle py.test with > our distribution and for an upcoming release we need the fixture features > in py.test 2.3, but we also need the bug fix from > https://bitbucket.org/hpk42/pytest/issue/213/issue-with-numpy-arrays-andthat > will be in 2.3.3. Is there any estimate for when 2.3.3 will be > released? We are hoping to do an AstroPy release in the next couple of > weeks. > > Thank you, > Matt 2.3.3 should go out next week cheers, holger > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev From issues-reply at bitbucket.org Mon Nov 5 02:17:18 2012 From: issues-reply at bitbucket.org (Alex Gaynor) Date: Mon, 05 Nov 2012 01:17:18 -0000 Subject: [py-dev] [hpk42/pytest] Add a new test hook that allows displaying custom information on an exception (issue #218) Message-ID: <630e9efbe4ba7d4ac7ff37b192ffb2ad@bitbucket.org> --- you can reply above this line --- New issue 218: Add a new test hook that allows displaying custom information on an exception https://bitbucket.org/hpk42/pytest/issue/218/add-a-new-test-hook-that-allows-displaying Alex Gaynor: Right now there's a hook that lets you display custom information in the event of an assertion failure. I'd like to have the same, except for in the event an exception is raised. Ideally it would a) let me display the original traceback, excactly as pytest normally would (and add extra info to it) b) let me filter on specific types of exceptions c) be as awesome as the rest of py.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-reply at bitbucket.org Mon Nov 5 22:42:14 2012 From: issues-reply at bitbucket.org (Alfredo Deza) Date: Mon, 05 Nov 2012 21:42:14 -0000 Subject: [py-dev] [hpk42/pytest] (some) Trove classifiers are missing (issue #219) Message-ID: <1326a73d58b547e1af079e4ff4f63e08@bitbucket.org> --- you can reply above this line --- New issue 219: (some) Trove classifiers are missing https://bitbucket.org/hpk42/pytest/issue/219/some-trove-classifiers-are-missing Alfredo Deza: It seems that with the last `py.test` release a few classifiers are not defined. This causes a bit of confusion when anyone wants to make sure that a given Python version is supported. I believe that Python 2.4 is no longer supported, it would be great if all the other versions that py.test supports could be set. -- 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 Nov 6 15:41:18 2012 From: holger at merlinux.eu (holger krekel) Date: Tue, 6 Nov 2012 14:41:18 +0000 Subject: [py-dev] pytest-2.3.3: integration fixes, py24 suport, */** args shown in traceback Message-ID: <20121106144118.GA27773@merlinux.eu> pytest-2.3.3: integration fixes, py24 suport, *args shown in traceback =========================================================================== pytest-2.3.3 is a another stabilization release of the py.test tool which offers uebersimple assertions, scalable fixture mechanisms and deep customization for testing with Python. Particularly, this release provides: - integration fixes and improvements related to flask, numpy, nose, unittest, mock - makes pytest work on py24 again (yes, people sometimes still need to use it) - show *,** args in pytest tracebacks Thanks to Manuel Jacob, Thomas Waldmann, Ronny Pfannschmidt, Pavel Repin and Andreas Taumoefolau for providing patches and all for the issues. See http://pytest.org/ for general information. To install or upgrade pytest: pip install -U pytest # or easy_install -U pytest best, holger krekel Changes between 2.3.2 and 2.3.3 ----------------------------------- - fix issue214 - parse modules that contain special objects like e. g. flask's request object which blows up on getattr access if no request is active. thanks Thomas Waldmann. - fix issue213 - allow to parametrize with values like numpy arrays that do not support an __eq__ operator - fix issue215 - split test_python.org into multiple files - fix issue148 - @unittest.skip on classes is now recognized and avoids calling setUpClass/tearDownClass, thanks Pavel Repin - fix issue209 - reintroduce python2.4 support by depending on newer pylib which re-introduced statement-finding for pre-AST interpreters - nose support: only call setup if its a callable, thanks Andrew Taumoefolau - fix issue219 - add py2.4-3.3 classifiers to TROVE list - in tracebacks *,** arg values are now shown next to normal arguments (thanks Manuel Jacob) - fix issue217 - support mock.patch with pytest's fixtures - note that you need either mock-1.0.1 or the python3.3 builtin unittest.mock. - fix issue127 - improve documentation for pytest_addoption() and add a ``config.getoption(name)`` helper function for consistency. From issues-reply at bitbucket.org Wed Nov 7 19:00:38 2012 From: issues-reply at bitbucket.org (Anonymous) Date: Wed, 07 Nov 2012 18:00:38 -0000 Subject: [py-dev] [hpk42/pytest] setup_class was not set correctly as class level (issue #220) Message-ID: <82d651ad006d2e796c307afb7e0b1c20@bitbucket.org> --- you can reply above this line --- New issue 220: setup_class was not set correctly as class level https://bitbucket.org/hpk42/pytest/issue/220/setup_class-was-not-set-correctly-as-class Anonymous: #test_d.py source: setup_class was called for each test cases, while teardown was called once import pytest import imp, sys, subprocess class TestD: @classmethod def setup_class(cls): print 1/0 def test_ssl_exchange_cert(self): assert 1==1 def test_verify(self): assert 1==1 @classmethod def teardown_class(cls): print 1/0 ######################################### #Output from console ######################################### ============================= test session starts ============================== platform linux2 -- Python 2.7.3 -- pytest-2.2.4 collecting ... collected 2 items test_d.py EEE ==================================== ERRORS ==================================== ________________ ERROR at setup of TestD.test_ssl_exchange_cert ________________ cls = @classmethod def setup_class(cls): > print 1/0 E ZeroDivisionError: integer division or modulo by zero test_d.py:8: ZeroDivisionError _____________________ ERROR at setup of TestD.test_verify ______________________ cls = @classmethod def setup_class(cls): > print 1/0 E ZeroDivisionError: integer division or modulo by zero test_d.py:8: ZeroDivisionError ____________________ ERROR at teardown of TestD.test_verify ____________________ cls = @classmethod def teardown_class(cls): > print 1/0 E ZeroDivisionError: integer division or modulo by zero test_d.py:21: ZeroDivisionError =========================== 3 error in 0.02 seconds ============================ -- 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-reply at bitbucket.org Thu Nov 8 15:09:36 2012 From: issues-reply at bitbucket.org (Anonymous) Date: Thu, 08 Nov 2012 14:09:36 -0000 Subject: [py-dev] [hpk42/pytest] PEP 420 namespace packages (issue #221) Message-ID: <5a88952d4121785888033c1861f01006@bitbucket.org> --- you can reply above this line --- New issue 221: PEP 420 namespace packages https://bitbucket.org/hpk42/pytest/issue/221/pep-420-namespace-packages Anonymous: It seems that pytest (I'm using 2.3.3) doesn't support PEP 420 style namespace packages. I'm trying to run the tests from XIST 4.4 and get the following results: ``` #!bash $ hg clone https://bitbucket.org/doerwalter/livinglogic.python.xist $ cd livinglogic.python.xist/ $ pip install . $ python -mpytest test/test_misc.py ========================================================================================================================= test session starts ========================================================================================================================= platform darwin -- Python 3.3.0 -- pytest-2.3.3 collected 19 items test/test_misc.py ................... ====================================================================================================================== 19 passed in 0.52 seconds ====================================================================================================================== ``` However if I remove the namespace package __init__.py file: ``` #!bash rm ~/pyvenvs/default/lib/python3.3/site-packages/ll_xist-4.4-py3.3-macosx-10.7-x86_64.egg/ll/__init__.py ``` The output of the test run looks like this: ``` #!bash $ python -mpytest test/test_misc.py ========================================================================================================================= test session starts ========================================================================================================================= platform darwin -- Python 3.3.0 -- pytest-2.3.3 collected 0 items / 1 errors =============================================================================================================================== ERRORS ================================================================================================================================ _________________________________________________________________________________________________________________ ERROR collecting test/test_misc.py __________________________________________________________________________________________________________________ test/test_misc.py:14: in > from ll import misc :1558: in _find_and_load > ??? :1516: in _find_and_load_unlocked > ??? :1470: in _find_module > ??? ../pyvenvs/default/lib/python3.3/site-packages/pytest-2.3.3-py3.3.egg/_pytest/assertion/rewrite.py:66: in find_module > fd, fn, desc = imp.find_module(lastname, path) ../.local/lib/python3.3/imp.py:192: in find_module > "not {}".format(type(name))) E RuntimeError: 'list' must be None or a list, not ======================================================================================================================= 1 error in 0.05 seconds ======================================================================================================================= ``` However using the package from within Python still works without a problem: ``` #!bash $ python Python 3.3.0 (default, Sep 29 2012, 23:56:05) [GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.57))] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ll import misc >>> misc.gzip(b'foo') b'\x1f\x8b\x08\x00\xb4\xbc\x9bP\x02\xffK\xcb\xcf\x07\x00!es\x8c\x03\x00\x00\x00' ``` -- 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-reply at bitbucket.org Fri Nov 9 10:58:47 2012 From: issues-reply at bitbucket.org (Ronny Pfannschmidt) Date: Fri, 09 Nov 2012 09:58:47 -0000 Subject: [py-dev] [hpk42/pytest] mark expressions break for items that dont have a obj property (issue #222) Message-ID: --- you can reply above this line --- New issue 222: mark expressions break for items that dont have a obj property https://bitbucket.org/hpk42/pytest/issue/222/mark-expressions-break-for-items-that-dont Ronny Pfannschmidt: https://bitbucket.org/RonnyPfannschmidt/pytest-codecheckers/issue/2/attributeerror-when-using-pytestmark-with -- 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-reply at bitbucket.org Fri Nov 9 12:10:15 2012 From: issues-reply at bitbucket.org (Sorin Sbarnea) Date: Fri, 09 Nov 2012 11:10:15 -0000 Subject: [py-dev] [hpk42/pytest] pytest fails collecting on py25 with "import file mismatch" - HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules (issue #223) Message-ID: --- you can reply above this line --- New issue 223: pytest fails collecting on py25 with "import file mismatch" - HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules https://bitbucket.org/hpk42/pytest/issue/223/pytest-fails-collecting-on-py25-with Sorin Sbarnea: I use tox + pytest to test my python module but pytest fails to run on python2.5 giving something like: ``` #!python import file mismatch: imported module 'tendo.ansiterm' has this __file__ attribute: /Users/sorins/dev/py/tendo/.tox/py25/lib/python2.5/site-packages/tendo/ansiterm.py which is not the same as the test file we want to collect: /Users/sorins/dev/py/tendo/tendo/ansiterm.py HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules ``` Please take a look at https://github.com/pycontribs/tendo I am running the tests with the `test` shell script from the repository root. Everything goes well for python 2.6 and 2.7 but for 2.5 pytest complains about this. I know that others had similar problems when they included the tests in the libraries but this should be possible, especially for small modules. -- 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-reply at bitbucket.org Sun Nov 11 18:19:52 2012 From: issues-reply at bitbucket.org (Anonymous) Date: Sun, 11 Nov 2012 17:19:52 -0000 Subject: [py-dev] [hpk42/pytest] a really large argument string will throw py.error.ENAMETOOLONG (issue #224) Message-ID: <5d03319a74501112c8d0982c4d8a4c61@bitbucket.org> --- you can reply above this line --- New issue 224: a really large argument string will throw py.error.ENAMETOOLONG https://bitbucket.org/hpk42/pytest/issue/224/a-really-large-argument-string-will-throw Anonymous: If you call py.test with something nefarious like this, config.py/getcfg() throws py.error.ENAMETOOLONG because it tries to make a file path from each command argument. py.test -m "flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py or flyingmonkey1.py" scripts/ I'm not sure if 'right' solution is to just not do this, or to catch this particular exception. try: if p.check(): # the rest of things except py.error.ENAMETOOLONG: continue -- 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-reply at bitbucket.org Wed Nov 14 08:19:37 2012 From: issues-reply at bitbucket.org (Thomas Waldmann) Date: Wed, 14 Nov 2012 07:19:37 -0000 Subject: [py-dev] [hpk42/pytest] finalizer function does not get called (issue #225) Message-ID: <58b800f51fd91cc4d40210233907eaa0@bitbucket.org> --- you can reply above this line --- New issue 225: finalizer function does not get called https://bitbucket.org/hpk42/pytest/issue/225/finalizer-function-does-not-get-called Thomas Waldmann: py.test 2.3.3 release from pypi :::python import pytest @pytest.fixture(scope="function") def fix(request): print "fix init" def fin(): print "fix finalize" request.addfinalizer(fin) return 42 def test_xxx(fix): print fix assert False Captured stdout: ------------------------------------------------------ fix init 42 ========== 1 failed in 0.03 seconds ============== -- 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 gardiac2002 at gmail.com Mon Nov 19 12:41:19 2012 From: gardiac2002 at gmail.com (Philipp Konrad) Date: Mon, 19 Nov 2012 12:41:19 +0100 Subject: [py-dev] Contributing to py Message-ID: Hello, my name is Philipp Konrad, I am a computer science student, a young Python programmer and researcher from Vienna, Austria. My developer experience started around two years ago in Java, but half year ago I was introduced to the Python world. I want to contribute to the py or py.test project and can assign one working day per week. Generally, I never have contributed to an open source project, so I would need some help for my first steps. - 1. Where is a good point to start? Is there a good site with first steps, a manual or something similiar? - 2. Do you have special coding / testing guidelines/ 'code of conduct' additional to PEP8? - 3. In which domain do you need new people? - 3.1 Code new features - 3.2 Documentation - 3.3 Write unit and integration tests - 3.4 Translation - 3.5 Community work - 4. Is there an organizational structure or hierachy that I should bear in mind? Take care, Philipp -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Mon Nov 19 13:25:49 2012 From: holger at merlinux.eu (holger krekel) Date: Mon, 19 Nov 2012 12:25:49 +0000 Subject: [py-dev] Contributing to py In-Reply-To: References: Message-ID: <20121119122549.GN27773@merlinux.eu> Hello Philipp, On Mon, Nov 19, 2012 at 12:41 +0100, Philipp Konrad wrote: > Hello, > > my name is Philipp Konrad, I am a computer science student, a young Python > programmer and researcher from Vienna, Austria. welcome! > My developer experience started around two years ago in Java, but half year > ago I was introduced to the Python world. > I want to contribute to the py or py.test project and can assign one > working day per week. Generally, I never have contributed > to an open source project, so I would need some help for my first steps. sure. "pytest" fits better than "py" to contribute to, i think. > - 1. Where is a good point to start? Is there a good site with first > steps, a manual or something similiar? This depends on your prior experience. To begin with, i assume your have walked through http://pytest.org including some of the examples. A few answers would help to better understand where you are starting from:: - Do you have experience in some form of automated testing? Have you played with nose, unittest? Played with pytest itself? - are you familiar with mercurial or git? Bitbucket.org? - Are you familiar with Python2 versus Python3 differences? - have written docutils/RestructuredText? - ever written a parser for configuration files? - written a distributed application? > - 2. Do you have special coding / testing guidelines/ 'code of conduct' > additional to PEP8? Apart from PEP8 not much apart from general good practise like e. g. not using any global state, writing a test for each feature added/bug fixed along with the actual change. Usually changes are developed in bitbucket clones and then you open a pull request. > - 3. In which domain do you need new people? > - 3.1 Code new features > - 3.2 Documentation > - 3.3 Write unit and integration tests > - 3.4 Translation > - 3.5 Community work All of these domains make some sense. You should probably try to tackled an issue listed in http://bitbucket.org/hpk42/pytest/issues - this will require reading up and understanding how pytest internally works. One bigger area would be to a) develop a pytest plugin for testing command line application b) rewrite pytest's own tests to use the plugin for a) i have a starting point including some specs and ideas. Other areas include for example writing a http server that allows to search/manage the many examples currently in sections of the rest-documents in doc/en/example/*. > - 4. Is there an organizational structure or hierachy that I should > bear in mind? Rather flat. It's probably best if you establish an IRC presence at irc.freenode.net . Apart from me (hpk42) there usually are "ronny" and "flub" who have contributed a lot of code already. Others have helped in various ways and may also be able to answer questions. best, holger From gardiac2002 at gmail.com Mon Nov 19 14:54:10 2012 From: gardiac2002 at gmail.com (Philipp Konrad) Date: Mon, 19 Nov 2012 14:54:10 +0100 Subject: [py-dev] Contributing to py In-Reply-To: <20121119122549.GN27773@merlinux.eu> References: <20121119122549.GN27773@merlinux.eu> Message-ID: Hello Holger, - Do you have experience in some form of automated testing? Have you played with nose, unittest? Played with pytest itself? > Regularly I use unittest and basic applications of pytest. So far, I never have used nose. - are you familiar with mercurial or git? Bitbucket.org? > No, I only used subversion. - Are you familiar with Python2 versus Python3 differences? > No, I have only used Python 2. - have written docutils/RestructuredText? > Yes, I used RestructuredText and create some documentation with Sphinx. - ever written a parser for configuration files? > Yes. - written a distributed application? > No. Great, so I will try to solve an issue from the bitbucket list. Can you recommend me one or should I just choose by myself? 2012/11/19 holger krekel > Hello Philipp, > > On Mon, Nov 19, 2012 at 12:41 +0100, Philipp Konrad wrote: > > Hello, > > > > my name is Philipp Konrad, I am a computer science student, a young > Python > > programmer and researcher from Vienna, Austria. > > welcome! > > > My developer experience started around two years ago in Java, but half > year > > ago I was introduced to the Python world. > > I want to contribute to the py or py.test project and can assign one > > working day per week. Generally, I never have contributed > > to an open source project, so I would need some help for my first steps. > > sure. "pytest" fits better than "py" to contribute to, i think. > > > - 1. Where is a good point to start? Is there a good site with first > > steps, a manual or something similiar? > > This depends on your prior experience. To begin with, i assume > your have walked through http://pytest.org including some of the examples. > A few answers would help to better understand where you are starting from:: > > - Do you have experience in some form of automated testing? Have you > played with nose, unittest? Played with pytest itself? > - are you familiar with mercurial or git? Bitbucket.org? > - Are you familiar with Python2 versus Python3 differences? > - have written docutils/RestructuredText? > - ever written a parser for configuration files? > - written a distributed application? > > > - 2. Do you have special coding / testing guidelines/ 'code of > conduct' > > additional to PEP8? > > Apart from PEP8 not much apart from general good practise like e. g. > not using any global state, writing a test for each feature added/bug fixed > along with the actual change. Usually changes are developed in bitbucket > clones and then you open a pull request. > > > - 3. In which domain do you need new people? > > - 3.1 Code new features > > - 3.2 Documentation > > - 3.3 Write unit and integration tests > > - 3.4 Translation > > - 3.5 Community work > > All of these domains make some sense. You should probably try to tackled > an issue listed in http://bitbucket.org/hpk42/pytest/issues - this will > require reading up and understanding how pytest internally works. > > One bigger area would be to > > a) develop a pytest plugin for testing command line application > b) rewrite pytest's own tests to use the plugin > > for a) i have a starting point including some specs and ideas. > > Other areas include for example writing a http server that allows to > search/manage the many examples currently in sections of the > rest-documents in doc/en/example/*. > > > - 4. Is there an organizational structure or hierachy that I should > > bear in mind? > > Rather flat. It's probably best if you establish an IRC presence at > irc.freenode.net . Apart from me (hpk42) there usually are "ronny" and > "flub" who have contributed a lot of code already. Others have helped > in various ways and may also be able to answer questions. > > best, > holger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Mon Nov 19 15:14:07 2012 From: holger at merlinux.eu (holger krekel) Date: Mon, 19 Nov 2012 14:14:07 +0000 Subject: [py-dev] Contributing to py In-Reply-To: References: <20121119122549.GN27773@merlinux.eu> Message-ID: <20121119141407.GO27773@merlinux.eu> On Mon, Nov 19, 2012 at 14:54 +0100, Philipp Konrad wrote: > Hello Holger, > > - Do you have experience in some form of automated testing? Have you > played with nose, unittest? Played with pytest itself? > > Regularly I use unittest and basic applications of pytest. So far, I > never have used nose. > > - are you familiar with mercurial or git? Bitbucket.org? > > No, I only used subversion. For contributing you will need to learn the basics of mercurial and bitbucket. > - Are you familiar with Python2 versus Python3 differences? > > No, I have only used Python 2. > > - have written docutils/RestructuredText? > > Yes, I used RestructuredText and create some documentation with Sphinx. > > - ever written a parser for configuration files? > > Yes. > > - written a distributed application? > > No. > > Great, so I will try to solve an issue from the bitbucket list. > Can you recommend me one or should I just choose by myself? Try to choose one. I feel a bit bad sending you to pytest source code without much guidance, though. If you can't make sense of it I can try to write up a bit of docs but that might last a few days. Let me just say that pytest's functionality is implemented almost entirely in plugins. The core and the plugins themselves usually call each other through hooks, defined in _pytest/hookspec.py. Whenever you see something like "*hook.pytest_*(...)" it is a call to such a hook, basically a 1:N relation because there might be multiple hook functions involved coming from multiple plugins. best, holger > > 2012/11/19 holger krekel > > > Hello Philipp, > > > > On Mon, Nov 19, 2012 at 12:41 +0100, Philipp Konrad wrote: > > > Hello, > > > > > > my name is Philipp Konrad, I am a computer science student, a young > > Python > > > programmer and researcher from Vienna, Austria. > > > > welcome! > > > > > My developer experience started around two years ago in Java, but half > > year > > > ago I was introduced to the Python world. > > > I want to contribute to the py or py.test project and can assign one > > > working day per week. Generally, I never have contributed > > > to an open source project, so I would need some help for my first steps. > > > > sure. "pytest" fits better than "py" to contribute to, i think. > > > > > - 1. Where is a good point to start? Is there a good site with first > > > steps, a manual or something similiar? > > > > This depends on your prior experience. To begin with, i assume > > your have walked through http://pytest.org including some of the examples. > > A few answers would help to better understand where you are starting from:: > > > > - Do you have experience in some form of automated testing? Have you > > played with nose, unittest? Played with pytest itself? > > - are you familiar with mercurial or git? Bitbucket.org? > > - Are you familiar with Python2 versus Python3 differences? > > - have written docutils/RestructuredText? > > - ever written a parser for configuration files? > > - written a distributed application? > > > > > - 2. Do you have special coding / testing guidelines/ 'code of > > conduct' > > > additional to PEP8? > > > > Apart from PEP8 not much apart from general good practise like e. g. > > not using any global state, writing a test for each feature added/bug fixed > > along with the actual change. Usually changes are developed in bitbucket > > clones and then you open a pull request. > > > > > - 3. In which domain do you need new people? > > > - 3.1 Code new features > > > - 3.2 Documentation > > > - 3.3 Write unit and integration tests > > > - 3.4 Translation > > > - 3.5 Community work > > > > All of these domains make some sense. You should probably try to tackled > > an issue listed in http://bitbucket.org/hpk42/pytest/issues - this will > > require reading up and understanding how pytest internally works. > > > > One bigger area would be to > > > > a) develop a pytest plugin for testing command line application > > b) rewrite pytest's own tests to use the plugin > > > > for a) i have a starting point including some specs and ideas. > > > > Other areas include for example writing a http server that allows to > > search/manage the many examples currently in sections of the > > rest-documents in doc/en/example/*. > > > > > - 4. Is there an organizational structure or hierachy that I should > > > bear in mind? > > > > Rather flat. It's probably best if you establish an IRC presence at > > irc.freenode.net . Apart from me (hpk42) there usually are "ronny" and > > "flub" who have contributed a lot of code already. Others have helped > > in various ways and may also be able to answer questions. > > > > best, > > holger > > From holger at merlinux.eu Mon Nov 19 19:38:34 2012 From: holger at merlinux.eu (holger krekel) Date: Mon, 19 Nov 2012 18:38:34 +0000 Subject: [py-dev] using tmpdir/monkeypatch/... from non-function scopes Message-ID: <20121119183834.GP27773@merlinux.eu> Hi folks, while writing tests on a new project using pytest-2.3 i noticed again an inconvience: fixtures such as tmpdir or monkeypatch could implementation-wise easily support being called from non-function scoped fixtures. But currently if you do:: @pytest.fixture(scope="module") def something(monkeypatch): ... you get a ScopeMismatchError because the function-scoped monkeypatch fixture cannot be called from a module-scoped fixture. I am considering introducing an "any" scope for a fixture declaration that would avoid this error. The "monkeypatch" and "something" fixture would then look like this:: @pytest.fixture(scope="any") def monkeypatch(...): # unmodified builtin monkeypatch implementation @pytest.fixture(scope="module") def something(monkeypatch): ... This would not raise a ScopeMismatchError but just work: monkeypatch-finalizers would be called when the last test in a module using the "something" fixture has run. However, if we additionally have a function-scoped fixture:: @pytest.fixture(scope="function") def other(monkeypatch): ... The "monkeypatch" instance could obviously not be the same object as the one in ``something(monkeypatch)`` above. monkeypatch-finalizers would raher be called after a test function using the "other" fixture has finalized. I am not sure if there is confusion potential about this. If there are any questions or comments, please shoot. best, holger From flub at devork.be Mon Nov 19 22:53:50 2012 From: flub at devork.be (Floris Bruynooghe) Date: Mon, 19 Nov 2012 21:53:50 +0000 Subject: [py-dev] using tmpdir/monkeypatch/... from non-function scopes In-Reply-To: <20121119183834.GP27773@merlinux.eu> References: <20121119183834.GP27773@merlinux.eu> Message-ID: Hello Holger, On 19 November 2012 18:38, holger krekel wrote: > But currently if you do:: > > @pytest.fixture(scope="module") > def something(monkeypatch): > ... > > you get a ScopeMismatchError because the function-scoped monkeypatch > fixture cannot be called from a module-scoped fixture. I agree this is a problem, I've worked around this using a hack in pytest-django for the live_server fixture: https://github.com/flub/pytest_django/blob/pytest23/pytest_django/fixtures.py#L180. In particular see the helper autouse fixture defined just below the fixture. For builtin fixtures I believe it is still possible to split up the session-scoped fixture into a session- and a function-scoped part to hack around this. It is ugly though. > I am considering > introducing an "any" scope for a fixture declaration that would avoid > this error. The "monkeypatch" and "something" fixture would then look > like this:: > > @pytest.fixture(scope="any") > def monkeypatch(...): > # unmodified builtin monkeypatch implementation > > @pytest.fixture(scope="module") > def something(monkeypatch): > ... > > This would not raise a ScopeMismatchError but just work: > monkeypatch-finalizers would be called when the last test in a module > using the "something" fixture has run. > > However, if we additionally have a function-scoped fixture:: > > @pytest.fixture(scope="function") > def other(monkeypatch): > ... > > The "monkeypatch" instance could obviously not be the same object as > the one in ``something(monkeypatch)`` above. monkeypatch-finalizers > would raher be called after a test function using the "other" > fixture has finalized. I am not sure if there is confusion potential > about this. For monkeypatch this would not be too bad as you can have two instances which don't cause harm to each other. But what happens with e.g. tmpdir? How can you avoid a temporary directory being created at the session-level and then later one at the function level? It's almost as the any-scoped fixture needs to be able to specify how things should be handled when it's requested from different scopes. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From holger at merlinux.eu Mon Nov 19 23:04:07 2012 From: holger at merlinux.eu (holger krekel) Date: Mon, 19 Nov 2012 22:04:07 +0000 Subject: [py-dev] using tmpdir/monkeypatch/... from non-function scopes In-Reply-To: References: <20121119183834.GP27773@merlinux.eu> Message-ID: <20121119220406.GQ27773@merlinux.eu> On Mon, Nov 19, 2012 at 21:53 +0000, Floris Bruynooghe wrote: > > @pytest.fixture(scope="any") > > def monkeypatch(...): > > # unmodified builtin monkeypatch implementation > > > > @pytest.fixture(scope="module") > > def something(monkeypatch): > > ... > > > > This would not raise a ScopeMismatchError but just work: > > monkeypatch-finalizers would be called when the last test in a module > > using the "something" fixture has run. > > > > However, if we additionally have a function-scoped fixture:: > > > > @pytest.fixture(scope="function") > > def other(monkeypatch): > > ... > > > > The "monkeypatch" instance could obviously not be the same object as > > the one in ``something(monkeypatch)`` above. monkeypatch-finalizers > > would raher be called after a test function using the "other" > > fixture has finalized. I am not sure if there is confusion potential > > about this. > > For monkeypatch this would not be too bad as you can have two > instances which don't cause harm to each other. But what happens with > e.g. tmpdir? How can you avoid a temporary directory being created at > the session-level and then later one at the function level? A tmpdir requested in function-scope and a tmpdir requested with session scope would be two different directories. I don't see a problem with this, do you? > It's almost as the any-scoped fixture needs to be able to specify how > things should be handled when it's requested from different scopes. An any-scoped fixture function can look at request.scope and act accordingly. An interesting question maybe is: how can a function-scoped resource _use_ itself but higher scoped :) (actually not too hard, i guess: you could just invent a fixture name, have its fixture function use a higher scope and pass through the resource (e. g. tmpdir). you can best and good night, holger From holger at merlinux.eu Tue Nov 20 08:27:00 2012 From: holger at merlinux.eu (holger krekel) Date: Tue, 20 Nov 2012 07:27:00 +0000 Subject: [py-dev] using tmpdir/monkeypatch/... from non-function scopes In-Reply-To: <20121119220406.GQ27773@merlinux.eu> References: <20121119183834.GP27773@merlinux.eu> <20121119220406.GQ27773@merlinux.eu> Message-ID: <20121120072700.GR27773@merlinux.eu> On Mon, Nov 19, 2012 at 22:04 +0000, holger krekel wrote: > > > the one in ``something(monkeypatch)`` above. monkeypatch-finalizers > > > would raher be called after a test function using the "other" > > > fixture has finalized. I am not sure if there is confusion potential > > > about this. > > > > For monkeypatch this would not be too bad as you can have two > > instances which don't cause harm to each other. But what happens with > > e.g. tmpdir? How can you avoid a temporary directory being created at > > the session-level and then later one at the function level? > > A tmpdir requested in function-scope and a tmpdir requested with session > scope would be two different directories. I don't see a problem with this, > do you? It's btw probably better to name it "each" as in "scope='each'" which makes it clearer that something happens for each scope separately. best, holger From flub at devork.be Tue Nov 20 10:52:46 2012 From: flub at devork.be (Floris Bruynooghe) Date: Tue, 20 Nov 2012 09:52:46 +0000 Subject: [py-dev] using tmpdir/monkeypatch/... from non-function scopes In-Reply-To: <20121119220406.GQ27773@merlinux.eu> References: <20121119183834.GP27773@merlinux.eu> <20121119220406.GQ27773@merlinux.eu> Message-ID: On 19 November 2012 22:04, holger krekel wrote: > A tmpdir requested in function-scope and a tmpdir requested with session > scope would be two different directories. I don't see a problem with this, > do you? When they both have a side-effect, like e.g. chdir, this could be an issue I thought. Also, which value does the test function see when it requests tmpdir in this case? I'm guessing it would get the tmpdir instance "closest" to itself, i.e. function-scope over module- or session-scope. But maybe it would be useful if it could also retrieve the value of other scopes? E.g. tmpdir.session_scope is the other tmpdir instance? Regards, Floris From flub at devork.be Tue Nov 20 10:55:27 2012 From: flub at devork.be (Floris Bruynooghe) Date: Tue, 20 Nov 2012 09:55:27 +0000 Subject: [py-dev] using tmpdir/monkeypatch/... from non-function scopes In-Reply-To: <20121120072700.GR27773@merlinux.eu> References: <20121119183834.GP27773@merlinux.eu> <20121119220406.GQ27773@merlinux.eu> <20121120072700.GR27773@merlinux.eu> Message-ID: On 20 November 2012 07:27, holger krekel wrote: > It's btw probably better to name it "each" as in "scope='each'" which > makes it clearer that something happens for each scope separately. agreed -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From holger at merlinux.eu Tue Nov 20 11:28:09 2012 From: holger at merlinux.eu (holger krekel) Date: Tue, 20 Nov 2012 10:28:09 +0000 Subject: [py-dev] using tmpdir/monkeypatch/... from non-function scopes In-Reply-To: References: <20121119183834.GP27773@merlinux.eu> <20121119220406.GQ27773@merlinux.eu> Message-ID: <20121120102808.GS27773@merlinux.eu> On Tue, Nov 20, 2012 at 09:52 +0000, Floris Bruynooghe wrote: > On 19 November 2012 22:04, holger krekel wrote: > > A tmpdir requested in function-scope and a tmpdir requested with session > > scope would be two different directories. I don't see a problem with this, > > do you? > > When they both have a side-effect, like e.g. chdir, this could be an > issue I thought. > > Also, which value does the test function see when it requests tmpdir > in this case? I'm guessing it would get the tmpdir instance "closest" > to itself, i.e. function-scope over module- or session-scope. But > maybe it would be useful if it could also retrieve the value of other > scopes? E.g. tmpdir.session_scope is the other tmpdir instance? if you need differentiation you could do:: @pytest.fixture(scope="module") def tmpdir_module(tmpdir): return tmpdir def test_function(tmpdir_module): ... Alternatively, we could think about:: @pytest.mark.usefixtures("tmpdir:module") def test_function(tmpdir): ... best, holger From holger at merlinux.eu Tue Nov 20 14:10:08 2012 From: holger at merlinux.eu (holger krekel) Date: Tue, 20 Nov 2012 13:10:08 +0000 Subject: [py-dev] pytest-2.3.4: bugfixes and extended selection with "-k expr" Message-ID: <20121120131008.GT27773@merlinux.eu> pytest-2.3.4: stabilization, more flexible selection via "-k expr" =========================================================================== pytest-2.3.4 is a small stabilization release of the py.test tool which offers uebersimple assertions, scalable fixture mechanisms and deep customization for testing with Python. This release comes with the following fixes and features: - make "-k" option accept an expressions the same as with "-m" so that one can write: -k "name1 or name2" etc. This is a slight usage incompatibility if you used special syntax like "TestClass.test_method" which you now need to write as -k "TestClass and test_method" to match a certain method in a certain test class. - allow to dynamically define markers via item.keywords[...]=assignment integrating with "-m" option - yielded test functions will now have autouse-fixtures active but cannot accept fixtures as funcargs - it's anyway recommended to rather use the post-2.0 parametrize features instead of yield, see: http://pytest.org/latest/example/parametrize.html - fix autouse-issue where autouse-fixtures would not be discovered if defined in a a/conftest.py file and tests in a/tests/test_some.py - fix issue226 - LIFO ordering for fixture teardowns - fix issue224 - invocations with >256 char arguments now work - fix issue91 - add/discuss package/directory level setups in example - fixes related to autouse discovery and calling Thanks in particular to Thomas Waldmann for spotting and reporting issues. See http://pytest.org/ for general information. To install or upgrade pytest: pip install -U pytest # or easy_install -U pytest best, holger krekel From adam at goucher.ca Mon Nov 26 17:25:29 2012 From: adam at goucher.ca (Adam Goucher) Date: Mon, 26 Nov 2012 11:25:29 -0500 Subject: [py-dev] steps to include a new plugin Message-ID: If I wanted to try and add https://github.com/adamgoucher/pytest-marks to the main pytest distribution. Is there a process for consideration, code style rules, etc.? The idea of this plugin is to allow script creators to not have to do @pytest.mark.red @pytest.mark.green @pytest.mark.blue @pytest.mark.black @pytest.mark.orange @pytest.mark.pink def some_test_method(self): # some check-y stuff but rather @pytest.marks('red', 'green', 'blue', 'black', 'orange', 'pink') def some_test_method(self): # some check-y stuff -adam From Ronny.Pfannschmidt at gmx.de Mon Nov 26 18:14:34 2012 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Mon, 26 Nov 2012 18:14:34 +0100 Subject: [py-dev] steps to include a new plugin In-Reply-To: References: Message-ID: <50B3A37A.60908@gmx.de> Hi Adam, i am having trouble seeing a good use-case for just throwing a bunch of marks at something, in my worldview marks are something to express intents/configurations so if there is an intent that combines more than one mark, i think that a function that properly configures/applies those marks might make more sense so at least i don?t see a place where i would use EXCESS markers an example that comes to my mind where your utility could help would be better creation of intent describing decorators eg. something like def needs_posixop(name): return pytest.marks( pytest.mark.posix, #? shortcuts that for nonmarkers? getattr(pytest.mark, name), pytest.mark.skip_if( not hasattr(os, name), reason='no %r in sys' %(name,)) ) @needs_posixop('dup') def test_foo(): ... however im a bit under the impression that instead of throwing in markers there, i'd would rather see something like the following @pytest.mark.needs_posixop('dup', 'dup2') def test_foo(): ... and having other marks be expanded from that maybe with a new hook called pytest_makeitem_expandmark (please find a better name) def pytest_makeitem_expandmarks(item, mark): if mark.name == 'needs_posixops' item.applymarker(pytest.mark.posix) for op in mark.args: item.applymarker(getattr(pytest.mark, op)) item.applymaker(pytest.mark.skip_if(...) so please provide a few more real world use-cases that make us see the merit of this utility once we understand more about how and where it will be useful, a normal pull request on bitbucket can be used to push patches that extend the builtin marks plugin with the new additions can be done best wishes, Ronny Pfannschmidt On 11/26/2012 05:25 PM, Adam Goucher wrote: > If I wanted to try and add https://github.com/adamgoucher/pytest-marks > to the main pytest distribution. Is there a process for consideration, > code style rules, etc.? > > The idea of this plugin is to allow script creators to not have to do > > @pytest.mark.red > @pytest.mark.green > @pytest.mark.blue > @pytest.mark.black > @pytest.mark.orange > @pytest.mark.pink > def some_test_method(self): > # some check-y stuff > > but rather > > @pytest.marks('red', 'green', 'blue', 'black', 'orange', 'pink') > def some_test_method(self): > # some check-y stuff > > -adam > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev From adam at goucher.ca Mon Nov 26 20:45:45 2012 From: adam at goucher.ca (Adam Goucher) Date: Mon, 26 Nov 2012 14:45:45 -0500 Subject: [py-dev] steps to include a new plugin In-Reply-To: <50B3A37A.60908@gmx.de> References: <50B397F9.604@goucher.ca> <50B3A37A.60908@gmx.de> Message-ID: I am using marks to dynamically determine which Selenium scripts to run. It is not uncommon for Se based suites to take many hours to complete so being able to only run the subsection you want is invaluable. And having the collection based on marks really hinders the ability of people writing scripts that are dependent on other ones (which hurts parallelism, etc.) More context; I use pytest as the underlying runner for a Selenium framework [1]. Since the scripts they create are 'functional' in nature they tend to cross various parts of their testing matrix. At minimum I coach them to have either 'shallow' or 'deep' as marks similar to how Google popularized the 'small', 'medium' and 'large' grouping. From there a method might have 'authentication', 'profile', 'admin' or any number of other marks of their choosing to slice-and-dice up their runs; 8 or 9 marks in not crazy in some suites I have seen. But yes, in your context I can see your approach being more suited for the task. -adam [1] http://element34.ca/saunter/pysaunter > Hi Adam, > > i am having trouble seeing a good use-case > for just throwing a bunch of marks at something, > > in my worldview marks are something to express intents/configurations > so if there is an intent that combines more than one mark, i think > that a function that properly configures/applies those marks > might make more sense > > so at least i don?t see a place where i would use EXCESS markers > > an example that comes to my mind where your utility could help would > be better creation of intent describing decorators > > eg. something like > > def needs_posixop(name): > return pytest.marks( > pytest.mark.posix, > #? shortcuts that for nonmarkers? > getattr(pytest.mark, name), > pytest.mark.skip_if( > not hasattr(os, name), > reason='no %r in sys' %(name,)) > ) > > @needs_posixop('dup') > def test_foo(): > ... > > > however im a bit under the impression that instead of throwing in > markers there, i'd would rather see something like the following > > > @pytest.mark.needs_posixop('dup', 'dup2') > def test_foo(): > ... > > and having other marks be expanded from that > > maybe with a new hook called pytest_makeitem_expandmark > (please find a better name) > > def pytest_makeitem_expandmarks(item, mark): > if mark.name == 'needs_posixops' > item.applymarker(pytest.mark.posix) > for op in mark.args: > item.applymarker(getattr(pytest.mark, op)) > item.applymaker(pytest.mark.skip_if(...) > > > so please provide a few more real world use-cases that make us see the > merit of this utility > > once we understand more about how and where it will be useful, > a normal pull request on bitbucket can be used to > push patches that extend the builtin marks plugin with the new > additions can be done > > best wishes, > Ronny Pfannschmidt > > > > On 11/26/2012 05:25 PM, Adam Goucher wrote: >> If I wanted to try and add https://github.com/adamgoucher/pytest-marks >> to the main pytest distribution. Is there a process for consideration, >> code style rules, etc.? >> >> The idea of this plugin is to allow script creators to not have to do >> >> @pytest.mark.red >> @pytest.mark.green >> @pytest.mark.blue >> @pytest.mark.black >> @pytest.mark.orange >> @pytest.mark.pink >> def some_test_method(self): >> # some check-y stuff >> >> but rather >> >> @pytest.marks('red', 'green', 'blue', 'black', 'orange', 'pink') >> def some_test_method(self): >> # some check-y stuff >> >> -adam >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev > From Ronny.Pfannschmidt at gmx.de Mon Nov 26 22:39:49 2012 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Mon, 26 Nov 2012 22:39:49 +0100 Subject: [py-dev] steps to include a new plugin In-Reply-To: References: <50B397F9.604@goucher.ca> <50B3A37A.60908@gmx.de> Message-ID: <50B3E1A5.1050706@gmx.de> Hi Adam, i took a few quick glances on pysaunter and the examples, It looks quite different from how *i* would expect it too look intuitively, which suggests that my understanding of your problem domain is too shallow. Also from what i can see so far pysaunter takes in things from unittest and unittest2 as well. Since your use of py.test is quite different from most other uses i have seen so far, i'd like to allocate some more time for understanding the problem later. Note that we might come up with a different path to solving the problem in order to be more in align with the other advanced features of py.test (which require avoiding unittest/unittest2 TestCase subclasses) For now i think it makes sense to keep the marks plugin separate, since its current form grew out of your use-cases and environment, which isn't quite comparable to the usual way py.test is used. When i find the time to understand the problem domain i'd like to get back at you. In particular, since i noticed that various parts of pysaunter and the examples could benefit from better integration in reporting and execution from the pytest side (which needs some more work in pytest itself) best wishes, Ronny Pfannschmidt On 11/26/2012 08:45 PM, Adam Goucher wrote: > I am using marks to dynamically determine which Selenium scripts to run. > It is not uncommon for Se based suites to take many hours to complete so > being able to only run the subsection you want is invaluable. And having > the collection based on marks really hinders the ability of people > writing scripts that are dependent on other ones (which hurts > parallelism, etc.) > > More context; I use pytest as the underlying runner for a Selenium > framework [1]. Since the scripts they create are 'functional' in nature > they tend to cross various parts of their testing matrix. At minimum I > coach them to have either 'shallow' or 'deep' as marks similar to how > Google popularized the 'small', 'medium' and 'large' grouping. From > there a method might have 'authentication', 'profile', 'admin' or any > number of other marks of their choosing to slice-and-dice up their runs; > 8 or 9 marks in not crazy in some suites I have seen. > > But yes, in your context I can see your approach being more suited for > the task. > > -adam > > [1] http://element34.ca/saunter/pysaunter >> Hi Adam, >> >> i am having trouble seeing a good use-case >> for just throwing a bunch of marks at something, >> >> in my worldview marks are something to express intents/configurations >> so if there is an intent that combines more than one mark, i think >> that a function that properly configures/applies those marks >> might make more sense >> >> so at least i don?t see a place where i would use EXCESS markers >> >> an example that comes to my mind where your utility could help would >> be better creation of intent describing decorators >> >> eg. something like >> >> def needs_posixop(name): >> return pytest.marks( >> pytest.mark.posix, >> #? shortcuts that for nonmarkers? >> getattr(pytest.mark, name), >> pytest.mark.skip_if( >> not hasattr(os, name), >> reason='no %r in sys' %(name,)) >> ) >> >> @needs_posixop('dup') >> def test_foo(): >> ... >> >> >> however im a bit under the impression that instead of throwing in >> markers there, i'd would rather see something like the following >> >> >> @pytest.mark.needs_posixop('dup', 'dup2') >> def test_foo(): >> ... >> >> and having other marks be expanded from that >> >> maybe with a new hook called pytest_makeitem_expandmark >> (please find a better name) >> >> def pytest_makeitem_expandmarks(item, mark): >> if mark.name == 'needs_posixops' >> item.applymarker(pytest.mark.posix) >> for op in mark.args: >> item.applymarker(getattr(pytest.mark, op)) >> item.applymaker(pytest.mark.skip_if(...) >> >> >> so please provide a few more real world use-cases that make us see the >> merit of this utility >> >> once we understand more about how and where it will be useful, >> a normal pull request on bitbucket can be used to >> push patches that extend the builtin marks plugin with the new >> additions can be done >> >> best wishes, >> Ronny Pfannschmidt >> >> >> >> On 11/26/2012 05:25 PM, Adam Goucher wrote: >>> If I wanted to try and add https://github.com/adamgoucher/pytest-marks >>> to the main pytest distribution. Is there a process for consideration, >>> code style rules, etc.? >>> >>> The idea of this plugin is to allow script creators to not have to do >>> >>> @pytest.mark.red >>> @pytest.mark.green >>> @pytest.mark.blue >>> @pytest.mark.black >>> @pytest.mark.orange >>> @pytest.mark.pink >>> def some_test_method(self): >>> # some check-y stuff >>> >>> but rather >>> >>> @pytest.marks('red', 'green', 'blue', 'black', 'orange', 'pink') >>> def some_test_method(self): >>> # some check-y stuff >>> >>> -adam >>> _______________________________________________ >>> py-dev mailing list >>> py-dev at codespeak.net >>> http://codespeak.net/mailman/listinfo/py-dev >> > From holger at merlinux.eu Tue Nov 27 23:27:53 2012 From: holger at merlinux.eu (holger krekel) Date: Tue, 27 Nov 2012 22:27:53 +0000 Subject: [py-dev] steps to include a new plugin In-Reply-To: References: Message-ID: <20121127222753.GA1720@merlinux.eu> Hi Adam, On Mon, Nov 26, 2012 at 11:25 -0500, Adam Goucher wrote: > If I wanted to try and add https://github.com/adamgoucher/pytest-marks > to the main pytest distribution. Is there a process for consideration, > code style rules, etc.? posting here is just fine. After discussion and agreement a pull request with tests and docs would be the next step. > The idea of this plugin is to allow script creators to not have to do > > @pytest.mark.red > @pytest.mark.green > @pytest.mark.blue > @pytest.mark.black > @pytest.mark.orange > @pytest.mark.pink > def some_test_method(self): > # some check-y stuff > > but rather > > @pytest.marks('red', 'green', 'blue', 'black', 'orange', 'pink') > def some_test_method(self): > # some check-y stuff I can see how each mark consuming a line can be cumbersome. I wonder if there would be a way to have less line noise, however. For example:: @pytest.mark.red.green.blue.black.orange.pink def test_method(...): ... best, holger > -adam > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev >