From Ronny.Pfannschmidt at gmx.de Tue Sep 1 01:59:20 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Tue, 01 Sep 2009 01:59:20 +0200 Subject: [py-dev] examples for programmatically running py.test and collecting the results in a custom way? Message-ID: <1251763160.25814.2.camel@localhost> hi, for the pida integration of py.test i could use some ideas on how to run it and how to iteratively collect the results./changes to the results for looponfail. Regards Ronny Pfannschmidt From holger at merlinux.eu Tue Sep 1 09:46:37 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 1 Sep 2009 09:46:37 +0200 Subject: [py-dev] examples for programmatically running py.test and collecting the results in a custom way? In-Reply-To: <1251763160.25814.2.camel@localhost> References: <1251763160.25814.2.camel@localhost> Message-ID: <20090901074637.GC15455@trillke.net> Hi Ronny, On Tue, Sep 01, 2009 at 01:59 +0200, Ronny Pfannschmidt wrote: > hi, > > for the pida integration of py.test i could use some ideas on how to run > it and how to iteratively collect the results./changes to the results > for looponfail. could you provide more context and what you conceptually or concretely need as an API? holger From Ronny.Pfannschmidt at gmx.de Tue Sep 1 10:18:47 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Tue, 01 Sep 2009 10:18:47 +0200 Subject: [py-dev] examples for programmatically running py.test and collecting the results in a custom way? In-Reply-To: <20090901074637.GC15455@trillke.net> References: <1251763160.25814.2.camel@localhost> <20090901074637.GC15455@trillke.net> Message-ID: <1251793127.25814.11.camel@localhost> On Tue, 2009-09-01 at 09:46 +0200, holger krekel wrote: > Hi Ronny, > > On Tue, Sep 01, 2009 at 01:59 +0200, Ronny Pfannschmidt wrote: > > hi, > > > > for the pida integration of py.test i could use some ideas on how to run > > it and how to iteratively collect the results./changes to the results > > for looponfail. > > could you provide more context and what you conceptually > or concretely need as an API? Lets try to outline, what i conceptually need. * knowdegde about what tests are run, and in what environment they are executed, preferably as somek kind of iterator * knowdegde about the results of those runs, their output, whatever other metadata pytest yields that might be helpfull is the basic need i have for running the tests once for the looponfail stuff there are some more needs i need to know about what tests: * are rerun as result of a failure * are added in a successive run * gone missing in this run due to a error * gone missing due to being removed from the unittests Ronny From holger at merlinux.eu Fri Sep 4 22:16:20 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 4 Sep 2009 22:16:20 +0200 Subject: [py-dev] py-trunk runs on python3 quite well now! Message-ID: <20090904201620.GU15455@trillke.net> Hi all, good news! py-trunk on bitbucket now runs rather well on top of Python 3.1.1 and remains compatible to python back to 2.4. Many thanks to Benjamin Peterson who contributed among other chunks new and simpler "assert" interpretation code - now enabled by default on CPython 2.5 till 3.1 Most everything works except for one functional test: distributed testing across the 3k version barrier. That would obviously be interesting to get working because it would allow unified test runs across all versions. Apart from the compatibility work i did tons of removal of old or unused code, reviewed and refactored tests and code to live in fewer files - aiming for much more readable source and a 1:1 mapping of namespaces to directory/file structure. best, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From holger at merlinux.eu Mon Sep 7 14:38:37 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 7 Sep 2009 14:38:37 +0200 Subject: [py-dev] jython and py.test code interaction Message-ID: <20090907123837.GD15455@trillke.net> Hi all, hi Benjamin, hi Frank (CCed), i played with Jython2.5.1rc1 and both py.test and py.execnet more or less work :) Here is a simple console session opening a connection from CPython to Jython for executing code dynamically: http://paste.pocoo.org/show/138497/ This means that one can interact with Java libraries and apps **from CPython** by firing up a Jython interpreter process and driving it with the "zero-install" execnet approach. The Jython interpreter can even be on a different machine :) py.test also runs on top of Jython but there are some issues with respect to showing tracebacks, here is a session obtained from execing jython2.5.1rc1 py/bin/py.test test/code/test_code.py --pastebin=all --> http://paste.pocoo.org/show/138496/ The py/code directory implements assert re-intepretation and source retrieval for dynamic code compilation which is e.g. used by py.test.raises(EXC, 'expression') in order to show nice tracebacks. Currently i see three major issues: * jython doesn't lookup AssertionError from the builtins (i filed http://bugs.jython.org/issue1461) * dynamic compilation, i.e. py.code.Code().new method: After adapting it to work with jython by using the new.code() call i noticed it doesn't preserve the co_filename object as cpython and pypy do. Maybe it's anyway better to keep a WeakValueDictionary with artifical-filename -> code mappings around and deprecate the new() method hack. * assert re-interpretation: no clue how this could work yet. any comments or offers for help welcome. best, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From holger at merlinux.eu Tue Sep 8 00:51:00 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 8 Sep 2009 00:51:00 +0200 Subject: [py-dev] jython and py.test code interaction In-Reply-To: <1afaf6160909071209q1c551522n539b895246ba6219@mail.gmail.com> References: <20090907123837.GD15455@trillke.net> <4dab5f760909071025h4d8b1088h9415d7862f277949@mail.gmail.com> <1afaf6160909071030u7244792du18dc1110d4c5a7a5@mail.gmail.com> <4dab5f760909071134h6535de3bydc3c9a64f300cc87@mail.gmail.com> <1afaf6160909071209q1c551522n539b895246ba6219@mail.gmail.com> Message-ID: <20090907225100.GF15455@trillke.net> On Mon, Sep 07, 2009 at 14:09 -0500, Benjamin Peterson wrote: > 2009/9/7 Frank Wierzbicki : > > On Mon, Sep 7, 2009 at 1:30 PM, Benjamin Peterson wrote: > >> 2009/9/7 Frank Wierzbicki : > >>> On Mon, Sep 7, 2009 at 8:38 AM, holger krekel wrote: > >>>> * assert re-interpretation: no clue how this could work yet. > >>> What is assert re-interpretation? > >> > >> When an assert statement fails, py.test tries to provide more > >> debugging information. It does this by walking over the AST of the > >> assert statement and reinterpreting each part to determine where > >> exactly it fails. > >> > >> I'm not sure why this wouldn't work on Jython except that my > >> implementation uses the ast module, which is not found in Python 2.5. > > We actually put the ast.py in our 2.5 -- but it does have a few > > incompatibilities (for example, we don't currently allow arbitrary > > python objects in attributes -- we attempt to convert them > > immediately) > > Well, assertion reinterpretation shouldn't need to do that, so I'm not > sure why it doesn't work. hum, i wouldn't bet that it doesn't work, actually - there were a number of failures in the (py/code) tests and i just *presumed* it wouldn't work. Maybe it works with the now fixed trunk. need to check that. best, holger From holger at merlinux.eu Tue Sep 8 10:16:26 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 8 Sep 2009 10:16:26 +0200 Subject: [py-dev] re-licensing to LGPL Message-ID: <20090908081625.GH15455@trillke.net> Hi all, as posted earlier in the 1.1 raodmap notes i just did the re-licensing to LGPL, also added an FAQ entry, see e.g. here: http://codespeak.net/py/trunk/faq.html#whygpl Let me know if you have any issues with this - preferably practical ones. I think i am somewhat familiar with the usual pro/con arguments for BSD/GPL style licenses so there is no need to repeat those. But i don't have a totally fixed opinion. cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From holger at merlinux.eu Tue Sep 8 18:25:20 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 8 Sep 2009 18:25:20 +0200 Subject: [py-dev] re-licensing to LGPL In-Reply-To: References: <20090908081625.GH15455@trillke.net> Message-ID: <20090908162520.GI15455@trillke.net> Hi Harald, nice to hear from you! On Tue, Sep 08, 2009 at 15:21 +0200, Massa, Harald Armin wrote: > Holger, > > the most practical reason: > > py.test should become the standard testing package for Python. There is no > better. > > the best of breed belongs to.... the standard library. > > and therefore the Python license is required, else it will be a non-starter. > > IF py.test does not want to become the best of breed of testing packages, > what is the reason to exist, anyway? wow, thanks for the appreciation! I heart Guido at Pycon 2008 saying that only "stable" software should enter the standard library. He added that in biology stable means dead. py.test is in motion and aims to work with many Python interpreters and environments. In fact, i rather believe that the python distribution and packaging world needs to change and improve instead of trying to push more stuff into a centralized library released with the top-level-version of CPython. Thankfully, Tarek Ziade and his fellowship of the packaging is moving along :) best, holger From lac at openend.se Tue Sep 8 18:50:04 2009 From: lac at openend.se (Laura Creighton) Date: Tue, 08 Sep 2009 18:50:04 +0200 Subject: [py-dev] re-licensing to LGPL In-Reply-To: Message from holger krekel of "Tue, 08 Sep 2009 18:25:20 +0200." <20090908162520.GI15455@trillke.net> References: <20090908081625.GH15455@trillke.net> <20090908162520.GI15455@trillke.net> Message-ID: <200909081650.n88Go4SC021666@theraft.openend.se> In a message of Tue, 08 Sep 2009 18:25:20 +0200, holger krekel writes: >Hi Harald, > >nice to hear from you! > >On Tue, Sep 08, 2009 at 15:21 +0200, Massa, Harald Armin wrote: >> Holger, >> >> the most practical reason: >> >> py.test should become the standard testing package for Python. There is > no >> better. >> >> the best of breed belongs to.... the standard library. >> >> and therefore the Python license is required, else it will be a non-sta >rter. >> >> IF py.test does not want to become the best of breed of testing package >s, >> what is the reason to exist, anyway? Actually, assuming that you wanted to put your software into the python standard library -- I know that Holger doesn't, but this is just to make it clear to any of you who are reading this and might have such ambitions -- THE PSF RECOMMENDS THAT YOU DO NOT USE THE PYTHON LICENSE. THE PSF does not accept the PSF license, either. Indeed, the only two licenses which are currently acceptable are the Academic Free License http://www.opensource.org/licenses/afl-3.0.php and the Apache license 2.0. http://www.opensource.org/licenses/apache2.0.php Read (some of the) gory details about why here: http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq And why can't Python relicense itself under a better license? Because the legal agreement that was entered into with CNRI prohibits changing the license. Just thought you should know this, even though Holger won't be affected since he doesn't want py.test to be part of the standard library. Laura From fdg001 at gmx.net Wed Sep 9 11:53:03 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Wed, 09 Sep 2009 10:53:03 +0100 Subject: [py-dev] using docstrings for test descriptions In-Reply-To: <4A58424A.3050400@gmx.net> References: <4A5315A9.5030401@gmx.net> <20090707102853.GL7437@trillke.net> <4A54EF91.9060004@gmx.net> <4A550A1A.8080803@gmx.net> <20090709114709.GP7437@trillke.net> <4A58424A.3050400@gmx.net> Message-ID: <4AA77AFF.6080900@gmx.net> After a few weeks of using py.test in anger, I realized that not having to write test descriptions made me much more productive. So I've reversed my original position and now think that py.test's focus on "rapid testing with minimal effort" actually works very well for me. Unless anyone has an actual need for this, I'm gonna treat it as YAGNI. -- F. From fijall at gmail.com Wed Sep 9 15:16:03 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 9 Sep 2009 07:16:03 -0600 Subject: [py-dev] jython and py.test code interaction In-Reply-To: <20090907123837.GD15455@trillke.net> References: <20090907123837.GD15455@trillke.net> Message-ID: <693bc9ab0909090616p6a094118tedacba2f08727305@mail.gmail.com> That's awesome. Btw, can we do the same with IronPython? This would potentially help testing stuff on the pypy cli backend. Cheers, fijal From fijall at gmail.com Wed Sep 9 15:20:31 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 9 Sep 2009 07:20:31 -0600 Subject: [py-dev] Feature proposition Message-ID: <693bc9ab0909090620y5c9e9ebr46773373dd77575f@mail.gmail.com> Hi. I have a feature proposition that I'm missing every now and then from py.test. Basically the idea is to be able to categorize tests with some keywords, other than just test name or part of it. Example: http://paste.pocoo.org/show/138853/ And I would like to be able to run py.test -k +foo for example to run TestFoo and TestOther (or some other syntax). The concrete use case is for example to mark all translation tests in pypy test suite (or part of it). Cheers, fijal From holger at merlinux.eu Wed Sep 9 21:36:00 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 9 Sep 2009 21:36:00 +0200 Subject: [py-dev] Feature proposition In-Reply-To: <693bc9ab0909090620y5c9e9ebr46773373dd77575f@mail.gmail.com> References: <693bc9ab0909090620y5c9e9ebr46773373dd77575f@mail.gmail.com> Message-ID: <20090909193600.GJ15455@trillke.net> Hi Maciej, > Hi. > > I have a feature proposition that I'm missing every now and then from > py.test. > Basically the idea is to be able to categorize tests with some > keywords, other than > just test name or part of it. Example: > > http://paste.pocoo.org/show/138853/ > > And I would like to be able to run py.test -k +foo for example to run > TestFoo and TestOther > (or some other syntax). makes sense i think. maybe as an extension to per-function "py.test.mark" decorators: class TestSomething: mark = ['foo'] so that you can also do: class TestSomething: mark = ['xfail'] (and eventually mark = ['skip'] - seems logical to have a declarative 'skip' and maybe an imperative 'xfail') > The concrete use case is for example to mark all translation tests in > pypy test suite > (or part of it). sure. There a few things that could be improved regarding keywords and keyword selection, i think. best, holger From holger at merlinux.eu Thu Sep 10 09:36:42 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 10 Sep 2009 09:36:42 +0200 Subject: [py-dev] execnet / GPL licensing Message-ID: <20090910073641.GO15455@trillke.net> Hi all, some of you know that i am considering licensing and general funding issues recently, see here for the current licensing status: http://codespeak.net/py/trunk/faq.html#whygpl However, i am considering releasing the execnet code under the GPL and the the rest under the LGPL. This would mean that execnet can be used in free software but not in proprietary software without getting a different license. I think execnet presents a unique and valuable approach to glueing Python interpreters and doing rapid deployment. It can particularly help with managing clouds of computers and I'd like to put more efforts into improving and extending in this area. And i'd like to tap into getting dual-licensing revenue. Which, on a side note, would flow back to me and e.g. http://merlinux.eu/people.html so we all can continue to work on great things. I am open to comments, arguments or bribes in the form of contracts for improvements :) cheers, holger Maybe also of interest to you (currently unreachable for me, though) http://www.fsf.org/licensing/licenses/why-not-lgpl.html -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From py-dev at tolomea.com Thu Sep 10 11:13:36 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Thu, 10 Sep 2009 19:13:36 +1000 Subject: [py-dev] execnet / GPL licensing In-Reply-To: <20090910073641.GO15455@trillke.net> References: <20090910073641.GO15455@trillke.net> Message-ID: Disclaimer: I appreciate that no one here is an IP lawyer and that any discussion doesn't count as legal advice. Just so I'm clear, as I understand it, if execnet were GPL then: 1: It would still be free (beer) for us to use and abuse any way we choose internally as long as we aren't distributing anything related to it. 2: Any modifications we made to it and distributed would be subject to GPL or the alternate license. 3: Any code derived from it that we distributed would be subject to GPL or the alternate license. 4: Any code that imports it that we distribute would be subject to GPL or the alternate license. 5: Alternatively the LGPL picture would be the same except 4 wouldn't apply. Please correct me if any of that is wrong. Assuming it is all correct then I have no problems with 1-3. Point 4 could be interesting, now the obvious scenario here would seem to be that we write some tool that uses execnet and wish to sell it and or make it publicly available. That scenario I have no problem with it is part and parcel of building things out of open source components. Indeed in that vein we have an internal tool that uses execnet that we are looking at distributing as open source. As you said "execnet presents a unique and valuable approach to glueing Python interpreters and doing rapid deployment". And the system we have built around it pushes that approach further and we would like to share that. But there is a more subtle example that concerns me, we are an embedded hardware company and use python (and more recently py lib) in our toolchain. Now imagine for the sake of discussion that we wanted to share some of that infrastructure with one of our B2B clients. Maybe we want to give them a drop of our testing infrastructure so they can use it to test products that contain our chips. I'm not sure if there is anything in the test infrastructure we would consider proprietary in that manner, but there definitely is in other areas of our infrastructure and py lib is becoming ever more popular internally. Under LGPL distributing this code in that manner would seem to be fine as we aren't distributing py lib or anything derived from it. What would be the implications of GPL licensing? and how do you see this scenario sitting with whatever alternate license you are considering? Gordon. On Thu, Sep 10, 2009 at 5:36 PM, holger krekel wrote: > Hi all, > > some of you know that i am considering licensing and general > funding issues recently, see here for the current licensing status: > > ? ?http://codespeak.net/py/trunk/faq.html#whygpl > > However, i am considering releasing the execnet code under the > GPL and the the rest under the LGPL. ?This would mean that execnet > can be used in free software but not in proprietary software > without getting a different license. > > I think execnet presents a unique and valuable approach to glueing > Python interpreters and doing rapid deployment. ?It can particularly > help with managing clouds of computers and I'd like to put more efforts > into improving and extending in this area. ?And i'd like to tap into > getting dual-licensing revenue. ?Which, on a side note, would flow back > to me and e.g. http://merlinux.eu/people.html so we all can continue to work > on great things. > > I am open to comments, arguments or bribes in the form > of contracts for improvements :) > > cheers, > > holger > > Maybe also of interest to you (currently unreachable for me, though) > http://www.fsf.org/licensing/licenses/why-not-lgpl.html > > -- > Metaprogramming, Python, Testing: http://tetamap.wordpress.com > Python, PyPy, pytest contracting: http://merlinux.eu > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > From holger at merlinux.eu Thu Sep 10 11:46:29 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 10 Sep 2009 11:46:29 +0200 Subject: [py-dev] execnet / GPL licensing In-Reply-To: References: <20090910073641.GO15455@trillke.net> Message-ID: <20090910094629.GP15455@trillke.net> On Thu, Sep 10, 2009 at 19:13 +1000, Gordon Wrigley wrote: > Disclaimer: I appreciate that no one here is an IP lawyer and that any > discussion doesn't count as legal advice. sure. Please also don't take my statements as legal advise, btw :) I know some good lawyers knowledgable in open source stuff, one of them having been a programmer before, so they can help if it comes to it :) > Just so I'm clear, as I understand it, if execnet were GPL then: > 1: It would still be free (beer) for us to use and abuse any way we > choose internally as long as we aren't distributing anything related > to it. > 2: Any modifications we made to it and distributed would be subject to > GPL or the alternate license. > 3: Any code derived from it that we distributed would be subject to > GPL or the alternate license. > 4: Any code that imports it that we distribute would be subject to GPL > or the alternate license. > 5: Alternatively the LGPL picture would be the same except 4 wouldn't apply. > > Please correct me if any of that is wrong. that's also my understanding. > Assuming it is all correct then I have no problems with 1-3. > > Point 4 could be interesting, now the obvious scenario here would seem > to be that we write some tool that uses execnet and wish to sell it > and or make it publicly available. That scenario I have no problem > with it is part and parcel of building things out of open source > components. Indeed in that vein we have an internal tool that uses > execnet that we are looking at distributing as open source. As you > said "execnet presents a unique and valuable approach to glueing > Python interpreters and doing rapid deployment". And the system we > have built around it pushes that approach further and we would like to > share that. cool. Curious i am :) > But there is a more subtle example that concerns me, we are an > embedded hardware company and use python (and more recently py lib) in > our toolchain. Now imagine for the sake of discussion that we wanted > to share some of that infrastructure with one of our B2B clients. > Maybe we want to give them a drop of our testing infrastructure so > they can use it to test products that contain our chips. I'm not sure > if there is anything in the test infrastructure we would consider > proprietary in that manner, but there definitely is in other areas of > our infrastructure and py lib is becoming ever more popular > internally. Under LGPL distributing this code in that manner would > seem to be fine as we aren't distributing py lib or anything derived > from it. Are you telling your clients to pre-install py lib? > What would be the implications of GPL licensing? You might need a separate agreement then. > and how do you see this scenario sitting with whatever > alternate license you are considering? All kinds of. I am sure we can find some fitting scheme for your case if GPL otherwise restricts your operations in undesirable ways. thanks for your clear and thoughtful response, btw. best, holger > On Thu, Sep 10, 2009 at 5:36 PM, holger krekel wrote: > > Hi all, > > > > some of you know that i am considering licensing and general > > funding issues recently, see here for the current licensing status: > > > > ? ?http://codespeak.net/py/trunk/faq.html#whygpl > > > > However, i am considering releasing the execnet code under the > > GPL and the the rest under the LGPL. ?This would mean that execnet > > can be used in free software but not in proprietary software > > without getting a different license. > > > > I think execnet presents a unique and valuable approach to glueing > > Python interpreters and doing rapid deployment. ?It can particularly > > help with managing clouds of computers and I'd like to put more efforts > > into improving and extending in this area. ?And i'd like to tap into > > getting dual-licensing revenue. ?Which, on a side note, would flow back > > to me and e.g. http://merlinux.eu/people.html so we all can continue to work > > on great things. > > > > I am open to comments, arguments or bribes in the form > > of contracts for improvements :) > > > > cheers, > > > > holger > > > > Maybe also of interest to you (currently unreachable for me, though) > > http://www.fsf.org/licensing/licenses/why-not-lgpl.html > > > > -- > > Metaprogramming, Python, Testing: http://tetamap.wordpress.com > > Python, PyPy, pytest contracting: http://merlinux.eu > > _______________________________________________ > > py-dev mailing list > > py-dev at codespeak.net > > http://codespeak.net/mailman/listinfo/py-dev > > > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From arigo at tunes.org Mon Sep 14 13:51:17 2009 From: arigo at tunes.org (Armin Rigo) Date: Mon, 14 Sep 2009 13:51:17 +0200 Subject: [py-dev] execnet / GPL licensing In-Reply-To: <20090910073641.GO15455@trillke.net> References: <20090910073641.GO15455@trillke.net> Message-ID: <20090914115117.GA14463@code0.codespeak.net> Hi, On Thu, Sep 10, 2009 at 09:36:42AM +0200, holger krekel wrote: > some of you know that i am considering licensing and general > funding issues recently, see here for the current licensing status: > > http://codespeak.net/py/trunk/faq.html#whygpl > > However, i am considering releasing the execnet code under the > GPL and the the rest under the LGPL. I don't know if it is possible to change the license without agreement from all parties that already contributed code. I would be rather opposed, in principle, to seeing my own code (12% of execnet, according to svn blame) being re-licensed LGPL or GPL. A bientot, Armin. From holger at merlinux.eu Wed Sep 16 15:07:58 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 16 Sep 2009 15:07:58 +0200 Subject: [py-dev] execnet / GPL licensing In-Reply-To: <20090914115117.GA14463@code0.codespeak.net> References: <20090910073641.GO15455@trillke.net> <20090914115117.GA14463@code0.codespeak.net> Message-ID: <20090916130758.GF15455@trillke.net> Hi Armin, On Mon, Sep 14, 2009 at 13:51 +0200, Armin Rigo wrote: > On Thu, Sep 10, 2009 at 09:36:42AM +0200, holger krekel wrote: > > some of you know that i am considering licensing and general > > funding issues recently, see here for the current licensing status: > > > > http://codespeak.net/py/trunk/faq.html#whygpl > > > > However, i am considering releasing the execnet code under the > > GPL and the the rest under the LGPL. > > I don't know if it is possible to change the license without agreement > from all parties that already contributed code. I would be rather > opposed, in principle, to seeing my own code (12% of execnet, according > to svn blame) being re-licensed LGPL or GPL. my understanding: Your contributions - e.g. most of rsync.py - would remain MIT licensed. Execnet distributed as a whole package could only be used under the GPL (if i GPL my parts and future work), however. Does that match your understanding? best, holger From py-dev at tolomea.com Thu Sep 17 03:07:20 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Thu, 17 Sep 2009 11:07:20 +1000 Subject: [py-dev] py.test crash Message-ID: This happened, I have no idea why or even who's fault it might be so I thought I'd post it here in case it means anything to anyone else. The test that was running uses execnet, it also creates a couple of additional threads. tests/tcp_behavior/test_basic_listen.py:3: test_function FAILTraceback (most recent call last) File "/usr/local/bin/py.test", line 8, in load_entry_point('py==1.0.0', 'console_scripts', 'py.test')() File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/cmdline/pytest.py", line 5, in main py.test.cmdline.main() File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/cmdline.py", line 16, in main exitstatus = session.main() File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/session.py", line 125, in main self.sessionfinishes(exitstatus=exitstatus) File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/session.py", line 93, in sessionfinishes exitstatus=exitstatus, File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", line 139, in __call__ return mc.execute(firstresult=self.firstresult) File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", line 23, in execute res = self.execute_method(currentmethod) File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", line 50, in execute_method return currentmethod(self, *self.args, **self.kwargs) File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/plugin/pytest_terminal.py", line 259, in pytest_sessionfinish __call__.execute() File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", line 23, in execute res = self.execute_method(currentmethod) File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", line 53, in execute_method return currentmethod(*self.args, **self.kwargs) File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/plugin/pytest_execnetcleanup.py", line 30, in pytest_sessionfinish gw.exit() File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/register.py", line 73, in exit super(PopenCmdGateway, self).exit() File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/gateway.py", line 354, in exit self._cleanup.unregister(self) File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/gateway.py", line 45, in unregister del self._activegateways[gateway] File "/usr/lib/python2.6/weakref.py", line 240, in __delitem__ del self.data[ref(key)] KeyError: gordonw at okum:~$ uname -a Linux okum 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:33:16 UTC 2009 i686 GNU/Linux gordonw at okum:~$ python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import py >>> py.version '1.0.0' From holger at merlinux.eu Thu Sep 17 10:21:50 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 17 Sep 2009 10:21:50 +0200 Subject: [py-dev] py.test crash In-Reply-To: References: Message-ID: <20090917082150.GH15455@trillke.net> Hi Gordon, could you check that it happens also with 1.0.2? holger On Thu, Sep 17, 2009 at 11:07 +1000, Gordon Wrigley wrote: > This happened, I have no idea why or even who's fault it might be so I > thought I'd post it here in case it means anything to anyone else. The > test that was running uses execnet, it also creates a couple of > additional threads. > > > tests/tcp_behavior/test_basic_listen.py:3: test_function FAILTraceback > (most recent call last) > File "/usr/local/bin/py.test", line 8, in > load_entry_point('py==1.0.0', 'console_scripts', 'py.test')() > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/cmdline/pytest.py", > line 5, in main > py.test.cmdline.main() > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/cmdline.py", > line 16, in main > exitstatus = session.main() > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/session.py", > line 125, in main > self.sessionfinishes(exitstatus=exitstatus) > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/session.py", > line 93, in sessionfinishes > exitstatus=exitstatus, > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > line 139, in __call__ > return mc.execute(firstresult=self.firstresult) > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > line 23, in execute > res = self.execute_method(currentmethod) > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > line 50, in execute_method > return currentmethod(self, *self.args, **self.kwargs) > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/plugin/pytest_terminal.py", > line 259, in pytest_sessionfinish > __call__.execute() > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > line 23, in execute > res = self.execute_method(currentmethod) > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > line 53, in execute_method > return currentmethod(*self.args, **self.kwargs) > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/plugin/pytest_execnetcleanup.py", > line 30, in pytest_sessionfinish > gw.exit() > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/register.py", > line 73, in exit > super(PopenCmdGateway, self).exit() > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/gateway.py", > line 354, in exit > self._cleanup.unregister(self) > File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/gateway.py", > line 45, in unregister > del self._activegateways[gateway] > File "/usr/lib/python2.6/weakref.py", line 240, in __delitem__ > del self.data[ref(key)] > KeyError: > > gordonw at okum:~$ uname -a > Linux okum 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:33:16 UTC > 2009 i686 GNU/Linux > gordonw at okum:~$ python > Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) > [GCC 4.3.3] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import py > >>> py.version > '1.0.0' > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From py-dev at tolomea.com Thu Sep 17 10:38:14 2009 From: py-dev at tolomea.com (Gordon Wrigley) Date: Thu, 17 Sep 2009 18:38:14 +1000 Subject: [py-dev] py.test crash In-Reply-To: <20090917082150.GH15455@trillke.net> References: <20090917082150.GH15455@trillke.net> Message-ID: sorry, I should have been clearer, to date it has only happened once, I wasn't doing anything unusal at the time just running the test set the same as always. On Thu, Sep 17, 2009 at 6:21 PM, holger krekel wrote: > Hi Gordon, > > could you check that it happens also with 1.0.2? > > holger > > On Thu, Sep 17, 2009 at 11:07 +1000, Gordon Wrigley wrote: >> This happened, I have no idea why or even who's fault it might be so I >> thought I'd post it here in case it means anything to anyone else. The >> test that was running uses execnet, it also creates a couple of >> additional threads. >> >> >> tests/tcp_behavior/test_basic_listen.py:3: test_function FAILTraceback >> (most recent call last) >> ? File "/usr/local/bin/py.test", line 8, in >> ? ? load_entry_point('py==1.0.0', 'console_scripts', 'py.test')() >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/cmdline/pytest.py", >> line 5, in main >> ? ? py.test.cmdline.main() >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/cmdline.py", >> line 16, in main >> ? ? exitstatus = session.main() >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/session.py", >> line 125, in main >> ? ? self.sessionfinishes(exitstatus=exitstatus) >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/session.py", >> line 93, in sessionfinishes >> ? ? exitstatus=exitstatus, >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", >> line 139, in __call__ >> ? ? return mc.execute(firstresult=self.firstresult) >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", >> line 23, in execute >> ? ? res = self.execute_method(currentmethod) >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", >> line 50, in execute_method >> ? ? return currentmethod(self, *self.args, **self.kwargs) >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/plugin/pytest_terminal.py", >> line 259, in pytest_sessionfinish >> ? ? __call__.execute() >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", >> line 23, in execute >> ? ? res = self.execute_method(currentmethod) >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", >> line 53, in execute_method >> ? ? return currentmethod(*self.args, **self.kwargs) >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/plugin/pytest_execnetcleanup.py", >> line 30, in pytest_sessionfinish >> ? ? gw.exit() >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/register.py", >> line 73, in exit >> ? ? super(PopenCmdGateway, self).exit() >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/gateway.py", >> line 354, in exit >> ? ? self._cleanup.unregister(self) >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/gateway.py", >> line 45, in unregister >> ? ? del self._activegateways[gateway] >> ? File "/usr/lib/python2.6/weakref.py", line 240, in __delitem__ >> ? ? del self.data[ref(key)] >> KeyError: >> >> gordonw at okum:~$ uname -a >> Linux okum 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:33:16 UTC >> 2009 i686 GNU/Linux >> gordonw at okum:~$ python >> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) >> [GCC 4.3.3] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import py >> >>> py.version >> '1.0.0' >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev >> > > -- > Metaprogramming, Python, Testing: http://tetamap.wordpress.com > Python, PyPy, pytest contracting: http://merlinux.eu > From holger at merlinux.eu Thu Sep 17 11:18:34 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 17 Sep 2009 11:18:34 +0200 Subject: [py-dev] py.test crash In-Reply-To: References: <20090917082150.GH15455@trillke.net> Message-ID: <20090917091834.GI15455@trillke.net> Hi Gordon, ok, it looks like a race condition on exiting gateways. Kind of known. And should work better with the next release due to the various cleanups. holger In trunk development i plan to do some more bits regarding On Thu, Sep 17, 2009 at 18:38 +1000, Gordon Wrigley wrote: > sorry, I should have been clearer, to date it has only happened once, > I wasn't doing anything unusal at the time just running the test set > the same as always. > > On Thu, Sep 17, 2009 at 6:21 PM, holger krekel wrote: > > Hi Gordon, > > > > could you check that it happens also with 1.0.2? > > > > holger > > > > On Thu, Sep 17, 2009 at 11:07 +1000, Gordon Wrigley wrote: > >> This happened, I have no idea why or even who's fault it might be so I > >> thought I'd post it here in case it means anything to anyone else. The > >> test that was running uses execnet, it also creates a couple of > >> additional threads. > >> > >> > >> tests/tcp_behavior/test_basic_listen.py:3: test_function FAILTraceback > >> (most recent call last) > >> ? File "/usr/local/bin/py.test", line 8, in > >> ? ? load_entry_point('py==1.0.0', 'console_scripts', 'py.test')() > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/cmdline/pytest.py", > >> line 5, in main > >> ? ? py.test.cmdline.main() > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/cmdline.py", > >> line 16, in main > >> ? ? exitstatus = session.main() > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/session.py", > >> line 125, in main > >> ? ? self.sessionfinishes(exitstatus=exitstatus) > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/session.py", > >> line 93, in sessionfinishes > >> ? ? exitstatus=exitstatus, > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > >> line 139, in __call__ > >> ? ? return mc.execute(firstresult=self.firstresult) > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > >> line 23, in execute > >> ? ? res = self.execute_method(currentmethod) > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > >> line 50, in execute_method > >> ? ? return currentmethod(self, *self.args, **self.kwargs) > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/plugin/pytest_terminal.py", > >> line 259, in pytest_sessionfinish > >> ? ? __call__.execute() > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > >> line 23, in execute > >> ? ? res = self.execute_method(currentmethod) > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/_com.py", > >> line 53, in execute_method > >> ? ? return currentmethod(*self.args, **self.kwargs) > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/test/plugin/pytest_execnetcleanup.py", > >> line 30, in pytest_sessionfinish > >> ? ? gw.exit() > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/register.py", > >> line 73, in exit > >> ? ? super(PopenCmdGateway, self).exit() > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/gateway.py", > >> line 354, in exit > >> ? ? self._cleanup.unregister(self) > >> ? File "/usr/local/lib/python2.6/dist-packages/py-1.0.0-py2.6.egg/py/execnet/gateway.py", > >> line 45, in unregister > >> ? ? del self._activegateways[gateway] > >> ? File "/usr/lib/python2.6/weakref.py", line 240, in __delitem__ > >> ? ? del self.data[ref(key)] > >> KeyError: > >> > >> gordonw at okum:~$ uname -a > >> Linux okum 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:33:16 UTC > >> 2009 i686 GNU/Linux > >> gordonw at okum:~$ python > >> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) > >> [GCC 4.3.3] on linux2 > >> Type "help", "copyright", "credits" or "license" for more information. > >> >>> import py > >> >>> py.version > >> '1.0.0' > >> _______________________________________________ > >> py-dev mailing list > >> py-dev at codespeak.net > >> http://codespeak.net/mailman/listinfo/py-dev > >> > > > > -- > > Metaprogramming, Python, Testing: http://tetamap.wordpress.com > > Python, PyPy, pytest contracting: http://merlinux.eu > > > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From arigo at tunes.org Fri Sep 18 14:18:48 2009 From: arigo at tunes.org (Armin Rigo) Date: Fri, 18 Sep 2009 14:18:48 +0200 Subject: [py-dev] execnet / GPL licensing In-Reply-To: <20090916130758.GF15455@trillke.net> References: <20090910073641.GO15455@trillke.net> <20090914115117.GA14463@code0.codespeak.net> <20090916130758.GF15455@trillke.net> Message-ID: <20090918121848.GA26602@code0.codespeak.net> Hi Holger, On Wed, Sep 16, 2009 at 03:07:58PM +0200, holger krekel wrote: > my understanding: Your contributions - e.g. most of rsync.py - > would remain MIT licensed. Execnet distributed as a whole > package could only be used under the GPL (if i GPL my parts > and future work), however. Does that match your understanding? I'm afraid not; I'm thinking notably about the reorganization of the execnet code I did long ago (around r13661), which still leaves e.g. 109 lines from me in channel.py (30%). I'm not really going to enforce my position in any way because I'm happy to stick with old versions of execnet for my own usage, but I'm just saying that I would informally consider this as *slightly* unfair reuse of my part of the work. Well, you might want to investigate the position of other people too (e.g. cfbolz and jan, who also have lines in channel.py). A bientot, Armin. From robert.kern at gmail.com Fri Sep 18 19:05:32 2009 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 18 Sep 2009 12:05:32 -0500 Subject: [py-dev] execnet / GPL licensing In-Reply-To: <20090918121848.GA26602@code0.codespeak.net> References: <20090910073641.GO15455@trillke.net> <20090914115117.GA14463@code0.codespeak.net> <20090916130758.GF15455@trillke.net> <20090918121848.GA26602@code0.codespeak.net> Message-ID: On 2009-09-18 07:18 AM, Armin Rigo wrote: > Hi Holger, > > On Wed, Sep 16, 2009 at 03:07:58PM +0200, holger krekel wrote: >> my understanding: Your contributions - e.g. most of rsync.py - >> would remain MIT licensed. Execnet distributed as a whole >> package could only be used under the GPL (if i GPL my parts >> and future work), however. Does that match your understanding? > > I'm afraid not; I'm thinking notably about the reorganization of the > execnet code I did long ago (around r13661), which still leaves e.g. 109 > lines from me in channel.py (30%). I'm not really going to enforce my > position in any way because I'm happy to stick with old versions of > execnet for my own usage, but I'm just saying that I would informally > consider this as *slightly* unfair reuse of my part of the work. Well, > you might want to investigate the position of other people too (e.g. > cfbolz and jan, who also have lines in channel.py). MIT licensed code may be combined with GPLed code to make a combined work that is distributed under the GPL. That's one of the things that you gave permission for people to do when you licensed your code under the MIT license. Your MIT license is still attached to your code, and Holger needs to make sure that he maintains the correct attribution and MIT license statement for your and others' code. Strictly speaking, he is not relicensing your code, just incorporating it according to the very permissive terms that you granted him. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From holger at merlinux.eu Mon Sep 21 17:58:10 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 21 Sep 2009 17:58:10 +0200 Subject: [py-dev] execnet / GPL licensing In-Reply-To: References: <20090910073641.GO15455@trillke.net> <20090914115117.GA14463@code0.codespeak.net> <20090916130758.GF15455@trillke.net> <20090918121848.GA26602@code0.codespeak.net> Message-ID: <20090921155810.GM15455@trillke.net> Hi Robert, Armin, On Fri, Sep 18, 2009 at 12:05 -0500, Robert Kern wrote: > On 2009-09-18 07:18 AM, Armin Rigo wrote: > > Hi Holger, > > > > On Wed, Sep 16, 2009 at 03:07:58PM +0200, holger krekel wrote: > >> my understanding: Your contributions - e.g. most of rsync.py - > >> would remain MIT licensed. Execnet distributed as a whole > >> package could only be used under the GPL (if i GPL my parts > >> and future work), however. Does that match your understanding? > > > > I'm afraid not; I'm thinking notably about the reorganization of the > > execnet code I did long ago (around r13661), which still leaves e.g. 109 > > lines from me in channel.py (30%). I'm not really going to enforce my > > position in any way because I'm happy to stick with old versions of > > execnet for my own usage, but I'm just saying that I would informally > > consider this as *slightly* unfair reuse of my part of the work. Well, > > you might want to investigate the position of other people too (e.g. > > cfbolz and jan, who also have lines in channel.py). > > MIT licensed code may be combined with GPLed code to make a combined work that > is distributed under the GPL. That's one of the things that you gave permission > for people to do when you licensed your code under the MIT license. Your MIT > license is still attached to your code, and Holger needs to make sure that he > maintains the correct attribution and MIT license statement for your and others' > code. Strictly speaking, he is not relicensing your code, just incorporating it > according to the very permissive terms that you granted him. right, thanks for the clarification. However, i can see some slight unfairness because i am breaking the possible assumtion that not only my past but also my future work would be published without any restrictions. best, holger From arigo at tunes.org Wed Sep 23 11:08:49 2009 From: arigo at tunes.org (Armin Rigo) Date: Wed, 23 Sep 2009 11:08:49 +0200 Subject: [py-dev] execnet / GPL licensing In-Reply-To: References: <20090910073641.GO15455@trillke.net> <20090914115117.GA14463@code0.codespeak.net> <20090916130758.GF15455@trillke.net> <20090918121848.GA26602@code0.codespeak.net> Message-ID: <20090923090849.GA32347@code0.codespeak.net> Hi, On Fri, Sep 18, 2009 at 12:05:32PM -0500, Robert Kern wrote: > MIT licensed code may be combined with GPLed code to make a combined work that > is distributed under the GPL. Absolutely right. Thanks Robert for the clarification -- I was wrong, of course. A bientot, Armin. From holger at merlinux.eu Wed Sep 23 19:06:44 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 23 Sep 2009 19:06:44 +0200 Subject: [py-dev] execnet / GPL licensing In-Reply-To: References: <20090910073641.GO15455@trillke.net> Message-ID: <20090923170644.GS15455@trillke.net> Hi Massa, On Wed, Sep 16, 2009 at 10:24 +0200, Massa, Harald Armin wrote: > Just to add a viewpoint ... > > I stumbled upon this article: > > http://www.stevestreeting.com/2009/09/15/my-evolving-view-of-open-source-licenses/ huh, this and the comments add a lot of viewpoints, not just one. > BeSD wishes, :) thanks to you and for all the feedback and advise. holger > Harald > > -- > GHUM Harald Massa > persuadere et programmare > Harald Armin Massa > Spielberger Stra?e 49 > 70435 Stuttgart > 0173/9409607 > no fx, no carrier pigeon > - > %s is too gigantic of an industry to bend to the whims of reality > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From digitalxero at gmail.com Sat Sep 26 03:56:28 2009 From: digitalxero at gmail.com (Dj Gilcrease) Date: Fri, 25 Sep 2009 19:56:28 -0600 Subject: [py-dev] Remote Distribution Message-ID: I know py.test has distributed testing already but I have been using Testswarm (a distributed javascript testing framework) for a while now and thought the idea would fit nicely with py.test. This is just me kind of brain storming the idea, so feel free to ignore me if you have no interest in this idea. Ok basic premise is: Central server for anyone to schedule test runs on Clients connect to the central server and run tests as they come in for any and all apps they meet the requirements for Goals: Eliminate the need for everyone to establish their own distributed testing network by establishing a remote distributed network where clients connect and will run tests from any app that is registered on the server. Brainstorm of requirements: Server - Needs a way for applications / libraries to register Server - Apps need a way to set dependencies, and a way to specify version for that dependency Server - Apps need a way to set the environments to test on (os version and python version) Server - Apps need a way to schedule test runs and upload the code to test against Server - Need a UI to display a test metric like http://testswarm.com/user/jquery/ Server - Needs a method of tracking available clients, and their environments Server - Needs a way to send tests to every available client that meets the environment specs for each app. Needs to keep track of the test run id for results Server - Needs to accept results back Needs to identify the run and clients environment id to make sure we can mark an environment finished for the run Server - Needs a fault catcher to reschedule a test run / environment if a remote client disconnects before it finished Server - Needs a way of removing code once all tests have been executed for a particular run, or after X days Server - Needs to ensure remote execution of apps is not possible for security Client - Needs a way to connect to the central server and keep it notified that it is still alive Client - Needs a way to receive Tests Client - Needs a way to report results back Brainstorm implementation details: modified? py.execnet for the server test dispatcher modified? py.execnet for the client test receiver Client should be command line only so it can be run as a service Web app for managing Apps and result display REsT API for scheduling test runs and uploading the required code? "py.test schedule" command? From Ronny.Pfannschmidt at gmx.de Sat Sep 26 13:34:29 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Sat, 26 Sep 2009 13:34:29 +0200 Subject: [py-dev] how to test fallbacks for missing modules? Message-ID: <1253964869.17339.18.camel@localhost> hi, i wonder what would be a good way to test the handling of unimportable modules or fallbacks for missing modules. i don't have any initial idea on how to get started with that. Regards Ronny From Ronny.Pfannschmidt at gmx.de Sat Sep 26 13:53:03 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Sat, 26 Sep 2009 13:53:03 +0200 Subject: [py-dev] lack of gui/async testing examples/documentation Message-ID: <1253965983.17339.21.camel@localhost> Hi, since im just right now in need to test async apps (a dbus service, and a gtk gui app with concurrency) i wanted to remind of the notorious lack of examples to figure how to do async testing propperly. Regards Ronny From holger at merlinux.eu Sat Sep 26 17:02:59 2009 From: holger at merlinux.eu (holger krekel) Date: Sat, 26 Sep 2009 17:02:59 +0200 Subject: [py-dev] how to test fallbacks for missing modules? In-Reply-To: <1253964869.17339.18.camel@localhost> References: <1253964869.17339.18.camel@localhost> Message-ID: <20090926150258.GE15455@trillke.net> Hi Ronny, > i wonder what would be a good way to test the handling of unimportable > modules or fallbacks for missing modules. > i don't have any initial idea on how to get started with that. what i usually do is to provide the to-be-unimportable module but put e.g. "raise ImportError()" into it. Using the 'tmpdir' and 'monkeypatch' funcargs makes it easy to do this, e.g.: def test_unimportable(tmpdir, monkeypatch): tmpdir.join("docutils.py").write("raise ImportError()") monkeypatch.setattr(sys, 'path', [str(tmpdir)] + sys.path) ..call-and-assert.. hth, holger From Ronny.Pfannschmidt at gmx.de Sat Sep 26 18:05:31 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Sat, 26 Sep 2009 18:05:31 +0200 Subject: [py-dev] how to test fallbacks for missing modules? In-Reply-To: <20090926150258.GE15455@trillke.net> References: <1253964869.17339.18.camel@localhost> <20090926150258.GE15455@trillke.net> Message-ID: <1253981131.17339.24.camel@localhost> On Sat, 2009-09-26 at 17:02 +0200, holger krekel wrote: > Hi Ronny, > > > i wonder what would be a good way to test the handling of unimportable > > modules or fallbacks for missing modules. > > i don't have any initial idea on how to get started with that. > > what i usually do is to provide the to-be-unimportable module > but put e.g. "raise ImportError()" into it. Using the 'tmpdir' > and 'monkeypatch' funcargs makes it easy to do this, e.g.: > > def test_unimportable(tmpdir, monkeypatch): > tmpdir.join("docutils.py").write("raise ImportError()") > monkeypatch.setattr(sys, 'path', [str(tmpdir)] + sys.path) > > ..call-and-assert.. unfortunately that doesnt help with modules that are already imported unless of course i use something like propper process based sandboxing for all tests (and i'd like to avoid that) From holger at merlinux.eu Sat Sep 26 18:19:56 2009 From: holger at merlinux.eu (holger krekel) Date: Sat, 26 Sep 2009 18:19:56 +0200 Subject: [py-dev] how to test fallbacks for missing modules? In-Reply-To: <1253981131.17339.24.camel@localhost> References: <1253964869.17339.18.camel@localhost> <20090926150258.GE15455@trillke.net> <1253981131.17339.24.camel@localhost> Message-ID: <20090926161956.GG15455@trillke.net> On Sat, Sep 26, 2009 at 18:05 +0200, Ronny Pfannschmidt wrote: > On Sat, 2009-09-26 at 17:02 +0200, holger krekel wrote: > > Hi Ronny, > > > > > i wonder what would be a good way to test the handling of unimportable > > > modules or fallbacks for missing modules. > > > i don't have any initial idea on how to get started with that. > > > > what i usually do is to provide the to-be-unimportable module > > but put e.g. "raise ImportError()" into it. Using the 'tmpdir' > > and 'monkeypatch' funcargs makes it easy to do this, e.g.: > > > > def test_unimportable(tmpdir, monkeypatch): > > tmpdir.join("docutils.py").write("raise ImportError()") > > monkeypatch.setattr(sys, 'path', [str(tmpdir)] + sys.path) > > > > ..call-and-assert.. > > unfortunately that doesnt help with modules that are already imported > unless of course i use something like propper process based sandboxing > for all tests (and i'd like to avoid that) yes, either requires running things in a new process or hacking 'sys.modules' as well - which you could all do through a nice funcarg. holger From Ronny.Pfannschmidt at gmx.de Sat Sep 26 18:36:11 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Sat, 26 Sep 2009 18:36:11 +0200 Subject: [py-dev] how to test fallbacks for missing modules? In-Reply-To: <20090926161956.GG15455@trillke.net> References: <1253964869.17339.18.camel@localhost> <20090926150258.GE15455@trillke.net> <1253981131.17339.24.camel@localhost> <20090926161956.GG15455@trillke.net> Message-ID: <1253982971.17339.27.camel@localhost> On Sat, 2009-09-26 at 18:19 +0200, holger krekel wrote: > On Sat, Sep 26, 2009 at 18:05 +0200, Ronny Pfannschmidt wrote: > > On Sat, 2009-09-26 at 17:02 +0200, holger krekel wrote: > > > Hi Ronny, > > > > > > > i wonder what would be a good way to test the handling of unimportable > > > > modules or fallbacks for missing modules. > > > > i don't have any initial idea on how to get started with that. > > > > > > what i usually do is to provide the to-be-unimportable module > > > but put e.g. "raise ImportError()" into it. Using the 'tmpdir' > > > and 'monkeypatch' funcargs makes it easy to do this, e.g.: > > > > > > def test_unimportable(tmpdir, monkeypatch): > > > tmpdir.join("docutils.py").write("raise ImportError()") > > > monkeypatch.setattr(sys, 'path', [str(tmpdir)] + sys.path) > > > > > > ..call-and-assert.. > > > > unfortunately that doesnt help with modules that are already imported > > unless of course i use something like propper process based sandboxing > > for all tests (and i'd like to avoid that) > > yes, either requires running things in a new process or hacking > 'sys.modules' as well - which you could all do through a nice funcarg. > you are right, a funcarg is on the wayfor simple cases, and im starting to see execnet as good way to wire up the more complex cases From holger at merlinux.eu Sun Sep 27 10:37:03 2009 From: holger at merlinux.eu (holger krekel) Date: Sun, 27 Sep 2009 10:37:03 +0200 Subject: [py-dev] Remote Distribution In-Reply-To: References: Message-ID: <20090927083703.GJ15455@trillke.net> Hi Dj, On Fri, Sep 25, 2009 at 19:56 -0600, Dj Gilcrease wrote: > I know py.test has distributed testing already but I have been using > Testswarm (a distributed javascript testing framework) for a while now > and thought the idea would fit nicely with py.test. This is just me > kind of brain storming the idea, so feel free to ignore me if you have > no interest in this idea. that's just fine! I am using the opportunity to add some brainstorming and fiction on a next-generation execnet/py.test :) > Ok basic premise is: > Central server for anyone to schedule test runs on > Clients connect to the central server and run tests as they come > in for any and all apps they meet the requirements for > > > Goals: > Eliminate the need for everyone to establish their own distributed > testing network by establishing a remote distributed network where > clients connect and will run tests from any app that is registered on > the server. i like the goal! > Brainstorm of requirements: > Server - Needs a way for applications / libraries to register > Server - Apps need a way to set dependencies, and a way to specify > version for that dependency > Server - Apps need a way to set the environments to test on (os > version and python version) > Server - Apps need a way to schedule test runs and upload the code > to test against > Server - Need a UI to display a test metric like > http://testswarm.com/user/jquery/ > Server - Needs a method of tracking available clients, and their > environments > Server - Needs a way to send tests to every available client that > meets the environment specs for each app. > Needs to keep track of the test run id for results > Server - Needs to accept results back > Needs to identify the run and clients environment id to make > sure we can mark an environment finished for the run > Server - Needs a fault catcher to reschedule a test run / > environment if a remote client disconnects before it finished > Server - Needs a way of removing code once all tests have been > executed for a particular run, or after X days > Server - Needs to ensure remote execution of apps is not possible > for security > Client - Needs a way to connect to the central server and keep it > notified that it is still alive > Client - Needs a way to receive Tests > Client - Needs a way to report results back makes sense. I'd like to allow to configure some aspects of remote environments, i.e. set up virtualenvs etc. See below. > Brainstorm implementation details: > modified? py.execnet for the server test dispatcher > modified? py.execnet for the client test receiver > Client should be command line only so it can be run as a service > Web app for managing Apps and result display > REsT API for scheduling test runs and uploading the required code? > "py.test schedule" command? I am currently pondering imperative schemes of setting up execnet-style networks. Triggered by your post i eventually wrote up some bits in my blog, see http://tinyurl.com/yco9aua Applied to testing distribution, here is what i would like to have for remote testing conceptually: py.test --tx platform=darwin//packages=django1.1,nose,... - would *discover* a darwin host from the above execnet network - create/use a fitting virtualenv with the given packages/versions - run tests in a new python process in that virtualenv - log results back to the invoking console A rather decentral system so far with no reporting. Something like py.test --runweb codespeak.net:9999 could dynamically fire up a web server at the specified host which then receives test results and it could also fire up a local browser window allowing to interact with the test run. The network so far is rather isolated. To build larger test networks there needs to be a way to "connect" two execnets. Maybe to make it publically available a command line like this would be nice: execnet publish mynet https://testrun.org/012983102938123 so that from another place people could issue execnet subscribe https://testrun.org/012983102938123 and the two execnets would be connected (whatever that means exactly). execnet list could list my local execnet's hosts and links to other execnets. So one could uniformly work with a multitude of dynamic user-contributed execnets at the fingertip of command line tools. i am happy about any feedback and already grateful for the opportunity to clarify my thoughts and plans :) cheers, holger From digitalxero at gmail.com Sun Sep 27 11:45:09 2009 From: digitalxero at gmail.com (Dj Gilcrease) Date: Sun, 27 Sep 2009 03:45:09 -0600 Subject: [py-dev] Remote Distribution In-Reply-To: <20090927083703.GJ15455@trillke.net> References: <20090927083703.GJ15455@trillke.net> Message-ID: On Sun, Sep 27, 2009 at 2:37 AM, holger krekel wrote: > makes sense. ?I'd like to allow to configure some aspects of > remote environments, i.e. set up virtualenvs etc. See below. I like the idea of using virtualenv as well > Applied to testing distribution, here is what i would like to have for > remote testing conceptually: > > ? ?py.test --tx platform=darwin//packages=django1.1,nose,... > > - would *discover* a darwin host from the above execnet network > - create/use a fitting virtualenv with the given packages/versions > - run tests in a new python process in that virtualenv > - log results back to the invoking console maybe use a pip requirements file instead of specifying each package individually. If I remember correctly pip is zero-install as well. Also it would be nice to have a platforms keyword so you can specify multiple platforms to run the test on without needing to run the command multiple times > > A rather decentral system so far with no reporting. ?Something like > > ? ?py.test --runweb codespeak.net:9999 > > could dynamically fire up a web server at the specified > host which then receives test results and it could also fire up > a local browser window allowing to interact with the test run. I like this and it eliminates the need for py.test to get out of scope by having and maintaining central web server where test results are collected and leaves it more to plugin creators to create plugins that will report back to a specified site if they want to have their one > > The network so far is rather isolated. ?To build larger > test networks there needs to be a way to "connect" two > execnets. ?Maybe to make it publically available a > command line like this would be nice: > > ? ?execnet publish mynet https://testrun.org/012983102938123 > > so that from another place people could issue > > ? ?execnet subscribe https://testrun.org/012983102938123 > > and the two execnets would be connected (whatever that > means exactly). > > ? ?execnet list > > could list my local execnet's hosts and links to other execnets. > So one could uniformly work with a multitude of dynamic > user-contributed execnets at the fingertip of > command line tools. I like this as well, just need an unsubscribe option, and a potentially a subscribe all option that would just subscribe to all published networks From issues-noreply at bitbucket.org Sun Sep 27 19:52:03 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sun, 27 Sep 2009 17:52:03 -0000 Subject: [py-dev] New issue 49 in py-trunk: figleaf plugin cannot be used Message-ID: <59244167b5f4acd997b262568d34bfde@bitbucket.org> New issue 49: figleaf plugin cannot be used http://bitbucket.org/hpk42/py-trunk/issue/49/figleaf-plugin-cannot-be-used Anonymous on Sun, 27 Sep 2009 19:52:02 +0200: Description: py 1.02, python 2.6, OS winxp 32 xp3 I installed py using easy_install figleaf plugin cannot be used tried py.test -F, no such option tried py.test -p figleaf, could not import plugin 'pytest_figleaf', reason: "could not import 'figleaf.annotate_html' "" -- 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 Mon Sep 28 19:49:42 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Mon, 28 Sep 2009 17:49:42 -0000 Subject: [py-dev] New issue 50 in py-trunk: cached_setup needs to cache correctly Message-ID: New issue 50: cached_setup needs to cache correctly http://bitbucket.org/hpk42/py-trunk/issue/50/cached_setup-needs-to-cache-correctly holger krekel / hpk42 on Mon, 28 Sep 2009 19:49:42 +0200: Description: Ronny pointed out that cached_setup does not work how one might assume: {{{ #!python def pytest_funcarg__one(request): return request.cached_setup(lambda: 42) def pytest_funcarg__two(request): return request.cached_setup(lambda: 17) def test_hello(one, two): # one and two will both be 42! }}} this is because the 'request' object is re-used across all function argument setups and the funcarg name is not stored on it. Needs to be better document or fixed - likely adding 'funcargname' as a key is the best approach even if it complicates the implemnetation a bit. 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 Mon Sep 28 19:55:20 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Mon, 28 Sep 2009 17:55:20 -0000 Subject: [py-dev] New issue 51 in py-trunk: there should be a way to have tests depend on the passing of other tests Message-ID: New issue 51: there should be a way to have tests depend on the passing of other tests http://bitbucket.org/hpk42/py-trunk/issue/51/there-should-be-a-way-to-have-tests-depend-on-the-passing-of-other RonnyPfannschmidt on Mon, 28 Sep 2009 19:55:20 +0200: Description: a good example would be something like the execnet serializer tests testing the serializer on different python versions needing gateways to work 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 Ronny.Pfannschmidt at gmx.de Tue Sep 29 00:33:00 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Tue, 29 Sep 2009 00:33:00 +0200 Subject: [py-dev] proposal: chaining pytest_generate_tests calls Message-ID: <1254177180.16914.42.camel@localhost> Hi, after some refactoring in the tests for the new serializer and some chat with Benjamin it got appearant that some form of chaining the pytest_generate_tests is helpfull and necessart. Since there are various details lurking around, this is a initial try to collect the needs for propperly chaining generate_tests calls. I will handle each aspect in a separate section. For each aspect i will add all items i currenly consider intresting/usefull, that might be incomplete and/or more than reasonable. Necessary Scopes ---------------- conftest/plugin Required to allow comfortable whole-project generators package/module the same goes for sub-groups of the tests functions doing special cases at the module level hook tends to be a mess see the current serializer tests for reasons Additional dimensions of variation that could proof usefull ------------------------------------------------------------ funcargs choose test generators based on the arguments a function explicitly takes, implicitly used funcargs via request.getfuncargvalue cant be considered there * marks using decorators to add values and the way to add them to the call Chaining order -------------- conftest plugin -> package -> subpackage -> module -> function building the test id's ------------------------- for just chaining the tests one can simply append to a tuple of id's for each successive add_call invokation per hook if variation on funcargs is considered one could show those like additional keyword parameters funcarg generators shouldn't support chaining themself, just use the closest matching test generator dealing with the param argument of addcall ------------------------------------------- * provide the value of the most close scope to request objecs * previous values of params could be accessible via linking to the precedessor of the current call or by providing a list ordered by scope * for funcarg variation it might be helpfull to supple the funcarg function with the param the funcarg related generator created dealing with the funcargs argument of addcall --------------------------------------------- * values from more close scope should override vales for less close scope * warnings could be printed for name-clashes/overrides how to actually combine the generators -------------------------------------- Note: early never released versions of the generate_tests feature provided implied combinations of all matching test generators, however that was fragile and got dumped for 'match most closest hook' i thenk we should prefer a explicit combination where for each addcall of an outer scope, the complete generate_tests function of the inner scope has to be run this results in a clean tree of invocations and better controll over the actual combinations regards Ronny Pfannschmidt From holger at merlinux.eu Tue Sep 29 20:46:17 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 29 Sep 2009 20:46:17 +0200 Subject: [py-dev] proposal: chaining pytest_generate_tests calls In-Reply-To: <1254177180.16914.42.camel@localhost> References: <1254177180.16914.42.camel@localhost> Message-ID: <20090929184617.GW15455@trillke.net> Hi Ronny, Benjamin, all, On Tue, Sep 29, 2009 at 00:33 +0200, Ronny Pfannschmidt wrote: > Hi, > > after some refactoring in the tests for the new serializer and some chat > with Benjamin it got appearant that some form of chaining the > pytest_generate_tests is helpfull and necessart. I am missing concise code examples to showcase what is missing and to understand concretely the issues and what you propose. From what i understand - for a function like this: def test_function(arg1, arg2): ... it's currently not easily possible to have a funcarg generator for arg1 and arg2 independently. I believe that this could be helped through a new attribute on the request object, like: for call in request.calls: # use call.id, call.param, call.funcargs request.addcall(...) If both the 'arg1' and 'arg2' generator are implenented this way they would collaborate to create m*n calls of the function. Another bit maybe is how to explicitely set funcarg factories, something like e.g.: @py.test.mark.genfuncarg(arg1=arg1factory, arg2=arg2factory) def test_function(arg1, arg2): ... This can be played with today through a custom pytest_generate_tests hook. I think the factories should be called with the request object. Experimentation and real-life usage is neccessary to settle details. It'd be great if we settled best/proven practises for parametrized/generated tests and did a plugin with docs on it. Any other comments? Or am i missing your points entirely? cheers, holger > Since there are various details lurking around, > this is a initial try to collect the needs for propperly chaining > generate_tests calls. > I will handle each aspect in a separate section. > For each aspect i will add all items i currenly consider > intresting/usefull, that might be incomplete and/or more than > reasonable. > > Necessary Scopes > ---------------- > > conftest/plugin > Required to allow comfortable whole-project generators > package/module > the same goes for sub-groups of the tests > functions > doing special cases at the module level hook tends to be a mess > see the current serializer tests for reasons note that you can also have funcargs at class level. > Additional dimensions of variation that could proof usefull > ------------------------------------------------------------ > > funcargs > choose test generators based on the arguments a function explicitly > takes, > implicitly used funcargs via request.getfuncargvalue cant be > considered there > * marks > using decorators to add values and the way to add them to the call > > > Chaining order > -------------- > > conftest plugin -> package -> subpackage -> module -> function > > > building the test id's > ------------------------- > > for just chaining the tests one can simply append to a tuple of id's for > each successive add_call invokation per hook > > if variation on funcargs is considered one could show those like > additional keyword parameters > > funcarg generators shouldn't support chaining themself, just use the > closest matching test generator > > dealing with the param argument of addcall > ------------------------------------------- > > * provide the value of the most close scope to request objecs > * previous values of params could be accessible via linking to the > precedessor of the current call or by providing a list ordered by scope > * for funcarg variation it might be helpfull to supple the funcarg > function with the param the funcarg related generator created > > > dealing with the funcargs argument of addcall > --------------------------------------------- > > * values from more close scope should override vales for less close > scope > * warnings could be printed for name-clashes/overrides > > > how to actually combine the generators > -------------------------------------- > > Note: early never released versions of the generate_tests feature > provided implied combinations of all matching test generators, however > that was fragile and got dumped for 'match most closest hook' > > i thenk we should prefer a explicit combination where for each addcall > of an outer scope, the complete generate_tests function of the inner > scope has to be run > > this results in a clean tree of invocations and better controll over the > actual combinations > > > regards Ronny Pfannschmidt > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu