From njriley at uiuc.edu  Sat Jul  1 06:59:58 2006
From: njriley at uiuc.edu (Nicholas Riley)
Date: Fri, 30 Jun 2006 23:59:58 -0500
Subject: [py-dev] requiring options; handling crashes
Message-ID: <20060701045958.GB52122@uiuc.edu>

Hi,

I am starting a new project and and am attempting to give this
test-development development thingy a try, so I am starting to use
py.test.  So far I'm finding it really natural and easy to understand
- especially compared with my short but unhappy experiences with
unittest writing tests for the Metakit Python binding.

I have a few questions.

First, is there a way to enforce options?  For some of the tests I am
using Psyco, which does not play happily with py.test without
--nomagic, so I would like to require this option.  I have tried
something like this in conftest.py:

	import py

	py.test.Config.parse(['--nomagic', '--nocapture', '--exitfirst'])

but that doesn't seem to work, and I'm not sure if there is supposed
to be a way.

Second, some of my tests crash the interpreter, so I'd prefer to test
every file individually (it's fine if no more tests run after the
crash :).  Is there a sensible way to nest py.test invocations such
that the results are aggregated?

If the above aren't possible at the moment, I would be interested in
implementing them; any hints as to a good design or where the code
should go would be appreciated.

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>

From hpk at trillke.net  Sun Jul  2 07:47:54 2006
From: hpk at trillke.net (holger krekel)
Date: Sun, 2 Jul 2006 07:47:54 +0200
Subject: [py-dev] requiring options; handling crashes
In-Reply-To: <20060701045958.GB52122@uiuc.edu>
References: <20060701045958.GB52122@uiuc.edu>
Message-ID: <20060702054754.GB5737@solar.trillke>

Hi Nicholas, 

you have two valid points - but i can't satisfyingly answer 
them right now.  Brief notes: 

* option parsing: please look at py/documentation/conftest.py 
  which adds options.  

* crashing interpreters: indeed, we should think about 
  how to run per-module interpreters.  There are hacks 
  for this (in pypy) but we need to think about a clean
  design. 

best, 

    holger

On Fri, Jun 30, 2006 at 23:59 -0500, Nicholas Riley wrote:
> Hi,
> 
> I am starting a new project and and am attempting to give this
> test-development development thingy a try, so I am starting to use
> py.test.  So far I'm finding it really natural and easy to understand
> - especially compared with my short but unhappy experiences with
> unittest writing tests for the Metakit Python binding.
> 
> I have a few questions.
> 
> First, is there a way to enforce options?  For some of the tests I am
> using Psyco, which does not play happily with py.test without
> --nomagic, so I would like to require this option.  I have tried
> something like this in conftest.py:
> 
> 	import py
> 
> 	py.test.Config.parse(['--nomagic', '--nocapture', '--exitfirst'])
> 
> but that doesn't seem to work, and I'm not sure if there is supposed
> to be a way.
> 
> Second, some of my tests crash the interpreter, so I'd prefer to test
> every file individually (it's fine if no more tests run after the
> crash :).  Is there a sensible way to nest py.test invocations such
> that the results are aggregated?
> 
> If the above aren't possible at the moment, I would be interested in
> implementing them; any hints as to a good design or where the code
> should go would be appreciated.
> 
> -- 
> Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 
merlinux GmbH       Steinbergstr. 42    31139 Hildesheim   
http://merlinux.de  tel +49 5121 20800 75 (fax 77) 

From brian at dorseys.org  Thu Jul  6 19:06:51 2006
From: brian at dorseys.org (Brian Dorsey)
Date: Thu, 6 Jul 2006 10:06:51 -0700
Subject: [py-dev] Fwd: [py-svn] r29699 - in py/dist/py/test: . testing
In-Reply-To: <20060706164521.0A4BD1009B@code0.codespeak.net>
References: <20060706164521.0A4BD1009B@code0.codespeak.net>
Message-ID: <66e877b70607061006o60fe63d7tb62d17c70c99420e@mail.gmail.com>

---------- Forwarded message ----------
> From: hpk at codespeak.net <hpk at codespeak.net>
<snip>
> Log:
> refine recursive and file filters for directories.
> follow the documentaiton (thanks to Fijal for pointing
> at the documentation inconsistency, i think that
> the 'whatever_test.py' convention is not actually used much)

Hmm... I use the 'whatever_test.py' format for all of my tests. I
admit, that I'm a bit strange, but somehow I like having the test
files right next to the module files since I always edit them in
pairs. Using the test_whatever.py format, all of the tests get sorted
together rather than right next to the files they are actually a test
of.

But, like I said, I'm a bit strange... I think most people like to
keep their tests in a separate directory?

Take care,
  -Brian

From hpk at trillke.net  Fri Jul  7 07:32:50 2006
From: hpk at trillke.net (holger krekel)
Date: Fri, 7 Jul 2006 07:32:50 +0200
Subject: [py-dev] Fwd: [py-svn] r29699 - in py/dist/py/test: . testing
In-Reply-To: <66e877b70607061006o60fe63d7tb62d17c70c99420e@mail.gmail.com>
References: <20060706164521.0A4BD1009B@code0.codespeak.net>
	<66e877b70607061006o60fe63d7tb62d17c70c99420e@mail.gmail.com>
Message-ID: <20060707053250.GN5737@solar.trillke>

Hi Brian!

On Thu, Jul 06, 2006 at 10:06 -0700, Brian Dorsey wrote:
> ---------- Forwarded message ----------
> > From: hpk at codespeak.net <hpk at codespeak.net>
> <snip>
> > Log:
> > refine recursive and file filters for directories.
> > follow the documentaiton (thanks to Fijal for pointing
> > at the documentation inconsistency, i think that
> > the 'whatever_test.py' convention is not actually used much)
> 
> Hmm... I use the 'whatever_test.py' format for all of my tests. I
> admit, that I'm a bit strange, but somehow I like having the test
> files right next to the module files since I always edit them in
> pairs. 
>
> Using the test_whatever.py format, all of the tests get sorted
> together rather than right next to the files they are actually a test
> of.

good point and actually the original one for introducing the 
whatever_test.py pattern. 
 
> But, like I said, I'm a bit strange... I think most people like to
> keep their tests in a separate directory?

yes, most do, i guess.  Nothing strange about not doing 
it - at least i am doing it myself as well. 

I was doing the change also to see if there is anyone
complaining.  I didn't have a plan for when that happens :)

OK, so what now?  I guess reverting to the old behaviour 
and documenting it (the complaint yesterday was that 
the "whatever_test" was not documented).  Could you do
that, Brian? I am still at a pypy sprint (grabbing my
first coffee and such) etc

best, 

    holger

From brian at dorseys.org  Fri Jul  7 20:38:03 2006
From: brian at dorseys.org (Brian Dorsey)
Date: Fri, 7 Jul 2006 11:38:03 -0700
Subject: [py-dev] Fwd: [py-svn] r29699 - in py/dist/py/test: . testing
In-Reply-To: <20060707053250.GN5737@solar.trillke>
References: <20060706164521.0A4BD1009B@code0.codespeak.net>
	<66e877b70607061006o60fe63d7tb62d17c70c99420e@mail.gmail.com>
	<20060707053250.GN5737@solar.trillke>
Message-ID: <66e877b70607071138o6778e84er5afe037d815f18a8@mail.gmail.com>

On 7/6/06, holger krekel <hpk at trillke.net> wrote:
> OK, so what now?  I guess reverting to the old behaviour
> and documenting it (the complaint yesterday was that
> the "whatever_test" was not documented).  Could you do
> that, Brian? I am still at a pypy sprint (grabbing my
> first coffee and such) etc

Sure, will do. It may be a day or so before I get a chance to do it.

Take care,
  -Brian

From Bryan.Weingarten at watchguard.com  Thu Jul 13 22:52:22 2006
From: Bryan.Weingarten at watchguard.com (Bryan Weingarten)
Date: Thu, 13 Jul 2006 13:52:22 -0700
Subject: [py-dev] license
Message-ID: <a5bcc619a08c08518f37c5df6040d46e47bee1b0@localhost>

I can't seem to find the license for py.lib (py.test) at the web site or
in the py-0.8.0-alpha2 package.  My company requires that we maintain a
reference to this before we can use it in our product.  So any pointers
to the license would be helpful. 

Thanks,

bryan

From jan at balster.info  Thu Jul 13 23:20:03 2006
From: jan at balster.info (Jan Balster)
Date: Thu, 13 Jul 2006 23:20:03 +0200
Subject: [py-dev] license
In-Reply-To: <a5bcc619a08c08518f37c5df6040d46e47bee1b0@localhost>
References: <a5bcc619a08c08518f37c5df6040d46e47bee1b0@localhost>
Message-ID: <44B6B903.4020702@balster.info>

Hey Bryan!

Nice to see you! Still no subversion hole in the firewall? ;)

You are finally using it your product? cool :)

py.lib is licensed under the MIT license.
If the license file is not in the tarball, you can find it in the subversion
repository:
http://codespeak.net/svn/py/dist/py/LICENSE

best,
  Jan

Bryan Weingarten wrote:
> I can't seem to find the license for py.lib (py.test) at the web site or
> in the py-0.8.0-alpha2 package.  My company requires that we maintain a
> reference to this before we can use it in our product.  So any pointers
> to the license would be helpful. 
> 
> Thanks,
> 
> bryan
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

From Bryan.Weingarten at watchguard.com  Fri Jul 14 00:14:14 2006
From: Bryan.Weingarten at watchguard.com (Bryan Weingarten)
Date: Thu, 13 Jul 2006 15:14:14 -0700
Subject: [py-dev] license
Message-ID: <cf6da4c534e84c793baadcfd766e18784aa8baa1@localhost>

hi jan,

thanks for replying.  actually, we just added subversion (webDAV)
capability this week.  webDAV uses commands that are extensions to the
http protocol which was just added to the firewall proxy.  the code is
checked in, so it should be available on the engineering firewall
whenever they do the next major upgrade.   

py.test is working out really well for us.  I've made it the standard
python unittest framework here and it's working well for everyone,
nothing but compliments.  so thanks for a great product.  today I was
customizing our embedded version of python that we will eventually
deliver with our products, adding and deleting files and packages
including py.lib. so unless I remove py.lib for some reason (and my
company doesn't go out of business :), py.lib should eventually be
installed on 10's of thousands of computers.

I plan to attend pycon 2007, so I'll see you again if you make it.


bryan


-----Original Message-----
From: Jan Balster [mailto:jan at balster.info] 
Sent: Thursday, July 13, 2006 2:20 PM
To: Bryan Weingarten
Cc: py lib developers
Subject: Re: [py-dev] license

Hey Bryan!

Nice to see you! Still no subversion hole in the firewall? ;)

You are finally using it your product? cool :)

py.lib is licensed under the MIT license.
If the license file is not in the tarball, you can find it in the
subversion
repository:
http://codespeak.net/svn/py/dist/py/LICENSE

best,
  Jan

Bryan Weingarten wrote:
> I can't seem to find the license for py.lib (py.test) at the web site
or
> in the py-0.8.0-alpha2 package.  My company requires that we maintain
a
> reference to this before we can use it in our product.  So any
pointers
> to the license would be helpful. 
> 
> Thanks,
> 
> bryan
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

From fijal at genesilico.pl  Fri Jul 14 12:01:52 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Fri, 14 Jul 2006 12:01:52 +0200
Subject: [py-dev] Import problems
Message-ID: <44B76B90.6000908@genesilico.pl>

  I want to make py.execnet import remotely. So what I perform:
- make new __import__ hook, so we can try local import or ask for 
sources from server (via some channel), sources are got by py.code.Source()

but...

  There are problems with importing py lib itself. For some modules it 
tells that there are builtin modules (py modules), because of import 
hooks. On the other hand copying py.lib is not what I want to achieve.
  Any clue?


From jan at balster.info  Fri Jul 14 12:39:05 2006
From: jan at balster.info (Jan Balster)
Date: Fri, 14 Jul 2006 12:39:05 +0200
Subject: [py-dev] Import problems
In-Reply-To: <44B76B90.6000908@genesilico.pl>
References: <44B76B90.6000908@genesilico.pl>
Message-ID: <44B77449.9010408@balster.info>

Hi Maciek,

about which python modules and pylib modules are you talking? Do you mean the
thread module? Can you provide some more informations?

A guess from my side:
These modules are included in the bootstrap code. Maybe the imports done in this
code are blocking your imports:

startup_modules = [
    'py.__.thread.io',
    'py.__.thread.pool',
    'py.__.execnet.inputoutput',
    'py.__.execnet.gateway',
    'py.__.execnet.message',
    'py.__.execnet.channel',
]


Maciek Fijalkowski wrote:
>   I want to make py.execnet import remotely. So what I perform:
> - make new __import__ hook, so we can try local import or ask for 
> sources from server (via some channel), sources are got by py.code.Source()
> 
> but...
> 
>   There are problems with importing py lib itself. For some modules it 
> tells that there are builtin modules (py modules), because of import 
> hooks. On the other hand copying py.lib is not what I want to achieve.
>   Any clue?
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

From benno at jeamland.net  Sun Jul 23 15:39:46 2006
From: benno at jeamland.net (Benno Rice)
Date: Sun, 23 Jul 2006 23:39:46 +1000
Subject: [py-dev] Greenlet module appears to be rebuilt on every import
Message-ID: <495E4BBA-60DD-4CE9-BA8D-8B71F0FB713A@jeamland.net>

Hi,

I'm running into an odd problem trying to use greenlets on Mac OS X  
10.4.7 with Python 2.4 built from DarwinPorts and the py lib from  
subversion as of 23 July 2006.

Whenever I try to import greenlets I get the following:

Python 2.4.3 (#1, Apr 20 2006, 12:04:55)
[GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from py.magic import greenlet
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/initpkg.py", line 180, in __getattr__
     result = self.__package__._resolve(extpy)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/initpkg.py", line 68, in _resolve
     implmodule = self._loadimpl(fspath[:-3])
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/initpkg.py", line 98, in _loadimpl
     return __import__(modpath, None, None, ['__doc__'])
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/magic/greenlet.py", line 5, in ?
     greenlet = path.getpymodule().greenlet
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/path/local/local.py", line 404, in  
getpymodule
     mod = make_module_from_c(self)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/misc/buildcmodule.py", line 37, in  
make_module_from_c
     lib.remove()
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/path/local/posix.py", line 111, in remove
     self._callex(os.remove, self.strpath)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/py/path/common.py", line 227, in _callex
     raise cls, value
py.error.EACCES: [Permission denied]: remove('/opt/local/Library/ 
Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/ 
py/c-extension/greenlet/greenlet.so',)

I've checked this out and it looks like something in the import logic  
wants to compile the greenlet module every time I import it.  This  
leads to two questions:

1) Shouldn't the greenlet module get built when I run the build  
target of the setup.py script?
2) Isn't this a rather large bug in normal operation since the site- 
packages directory should be owned by root?

Is there a way to have the greenlet module be built once during the  
build phase of setup.py and then just used statically after that?

-- 
Benno Rice
benno at jeamland.net
http://jeamland.net/



From ondrej at certik.cz  Wed Aug  9 21:31:43 2006
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 9 Aug 2006 15:31:43 -0400
Subject: [py-dev] py.execnet example bug
Message-ID: <85b5c3130608091231h1ab96147g2296a2130bc4229f@mail.gmail.com>

Hi, I tried this example:

http://codespeak.net/py/current/doc/execnet.html#a-simple-and-useful-example-for-channels

and it seems it doesn't work for me -

I had to change this:

        for fn in channel.receive():
            f = open(fn, 'rb')
            try:
                channel.send(f.read())
            finally:
                f.close()

to this:

            try:
                while 1:
                    fn=channel.receive()
                    f = open(fn, 'rb')
                    try:
                        channel.send(f.read())
                    finally:
                        f.close()
            except:
                pass

to make it work. The problem is, that channel.receive() returns a
string (a filename), and the for loop then iterates over the
characters of the filename, which is obviously not what was intended.
Am I doing something wrong, or is it a bug?

Ondrej

From hpk at trillke.net  Thu Aug 10 07:11:14 2006
From: hpk at trillke.net (holger krekel)
Date: Thu, 10 Aug 2006 07:11:14 +0200
Subject: [py-dev] py.execnet example bug
In-Reply-To: <85b5c3130608091231h1ab96147g2296a2130bc4229f@mail.gmail.com>
References: <85b5c3130608091231h1ab96147g2296a2130bc4229f@mail.gmail.com>
Message-ID: <20060810051114.GT22199@solar.trillke.net>

Hi Ondrej, 

On Wed, Aug 09, 2006 at 15:31 -0400, Ondrej Certik wrote:
> Hi, I tried this example:
> 
> http://codespeak.net/py/current/doc/execnet.html#a-simple-and-useful-example-for-channels
> 
> and it seems it doesn't work for me -
> 
> I had to change this:
> 
>         for fn in channel.receive():
>             f = open(fn, 'rb')
>             try:
>                 channel.send(f.read())
>             finally:
>                 f.close()
> 
> to this:
> 
>             try:
>                 while 1:
>                     fn=channel.receive()
>                     f = open(fn, 'rb')
>                     try:
>                         channel.send(f.read())
>                     finally:
>                         f.close()
>             except:
>                 pass
> 
> to make it work. The problem is, that channel.receive() returns a
> string (a filename), and the for loop then iterates over the
> characters of the filename, which is obviously not what was intended.
> Am I doing something wrong, or is it a bug?

The original intention was: 

    for fn in channel:   # no .receive() here 
        ...

was the original intention and it should work (the iteration over 
a channel will raise StopIteration when the other side closes it). 
I fixed the example.  

Your replacement above is fine, but the "error" handling 
is a bit rough: just swallowing all exceptions makes it 
somewhat hard to detect for the other side to notice
(and make sense out of) the error.  It's probably better to
have a "try:except:" within the for-loop block and send
back a tuple encoding error information. (You cannot send
"user" objects, only marshallable objects, i.e. dicts, tuples, 
lists, of strings/ints/dicts/tuples/lists...)

best and HTH, 

    holger

From ondrej at certik.cz  Thu Aug 10 16:04:24 2006
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 10 Aug 2006 10:04:24 -0400
Subject: [py-dev] py.execnet example bug
In-Reply-To: <20060810051114.GT22199@solar.trillke.net>
References: <85b5c3130608091231h1ab96147g2296a2130bc4229f@mail.gmail.com>
	<20060810051114.GT22199@solar.trillke.net>
Message-ID: <85b5c3130608100704h599e3df3o96488b0f070a82cc@mail.gmail.com>

> Your replacement above is fine, but the "error" handling
> is a bit rough: just swallowing all exceptions makes it
> somewhat hard to detect for the other side to notice
> (and make sense out of) the error.  It's probably better to
> have a "try:except:" within the for-loop block and send
> back a tuple encoding error information. (You cannot send
> "user" objects, only marshallable objects, i.e. dicts, tuples,
> lists, of strings/ints/dicts/tuples/lists...)

Thanks. Yes, it was just a rough quickfix to make it work somehow.

Ondrej

From hpk at trillke.net  Tue Aug 29 07:59:15 2006
From: hpk at trillke.net (holger krekel)
Date: Tue, 29 Aug 2006 07:59:15 +0200
Subject: [py-dev] merging new distributed testing approach
Message-ID: <20060829055915.GY21969@solar.trillke.net>

Hi folks, 

Maciej Fijalkowski (as part of his Summer of PyPy involvement)
and me nicely sprinted in Ireland a couple of days on evolving
py.test to perform ad-hoc distributed testing.  The work is
living in this branch 

    https://codespeak.net/svn/py/branch/distributed 

and incorporates a partial rewrite of the session and reporting 
logic.  With "py.test --session=R" the new 
py/test/resssion/rsession.py's RSession will come into play
and distribute tests to a number of ssh-address specified 
hosts.  The ssh-hosts need to be specified in a conftest.py 
with "disthosts=['sshaddress1', 'sshaddress2', ...]" 
The new session object does not implement all the 
TerminalSession's options yet. 

As only a few refactorings/refinements were needed in the rest 
of the py lib, and the current py.test logic continues to be 
in effect by default, Maciej and me intend to merge the 
branch this week to simplify development and have more early
users.  

If you notice any behaviour regressions for the still non-distributed 
py.test default running, please notify here on the list or on the issue
tracker.  It then remains to be seen when/how we declare the
non-distributed case a special case of the distributed one. 

best, 

    holger

-- 
merlinux GmbH       Steinbergstr. 42    31139 Hildesheim   
http://merlinux.de  tel +49 5121 20800 75 (fax 77) 

From alex.j.ross at gmail.com  Wed Aug 30 03:10:22 2006
From: alex.j.ross at gmail.com (Alexander Ross)
Date: Tue, 29 Aug 2006 18:10:22 -0700
Subject: [py-dev] Patch to py/path/local/common.py
Message-ID: <e182bee20608291810k5dd88f4cg6ce3ee1ed79973b8@mail.gmail.com>

Compiling the file `py/path/local/common.py` with python2.2 results in
a SyntaxError.  This keeps `py.test --exec=python2.2` from running as
advertised.  I was able to patch `py/path/local/common.py` so that it
will work with python2.2.  I don't know if this breaks anything, but
it has worked for me so far.

Index: py/path/local/common.py
===================================================================
--- py/path/local/common.py     (revision 31816)
+++ py/path/local/common.py     (working copy)
@@ -5,18 +5,17 @@
         self.path = path
         self._osstatresult = osstatresult
-    for name in ('atime blksize blocks ctime dev gid '
+    for name in ('atime blksize blocks ctime dev gid '
                  'ino mode mtime nlink rdev size uid'.split()):
-        exec """if 1:
-            def fget(self):
-                return getattr(self._osstatresult, "st_%(name)s", None)
-            %(name)s = property(fget)
-            def fget_deprecated(self):
-                py.std.warnings.warn("statresult.st_%(name)s is
deprecated, use "
-                                     "statresult.%(name)s instead.",
-                                     DeprecationWarning, stacklevel=2)
-                return getattr(self._osstatresult, "st_%(name)s", None)
-            st_%(name)s = property(fget_deprecated)""" % locals()
+        exec """def fget(self):
+    return getattr(self._osstatresult, "st_%(name)s", None)
+%(name)s = property(fget)
+def fget_deprecated(self):
+    py.std.warnings.warn("statresult.st_%(name)s is deprecated, use "
+                         "statresult.%(name)s instead.",
+                         DeprecationWarning, stacklevel=2)
+    return getattr(self._osstatresult, "st_%(name)s", None)
+st_%(name)s = property(fget_deprecated)""" % locals()
     del fget
     del fget_deprecated

From fijal at genesilico.pl  Fri Sep 15 11:46:35 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Fri, 15 Sep 2006 11:46:35 +0200
Subject: [py-dev] RLimit
Message-ID: <450A767B.6070805@genesilico.pl>

[I'm sending it here, to persist at some point and I'm too lazy to add 
it to docs]

It should be very nice to have some feature in py.test which allows you 
to specify rlimit for tests and fail/skip tests which are beyond this 
limit. Especially for distributed testing this makes more sense (as well 
as nice-ing stuff).