From jjinux at gmail.com  Wed Oct  4 23:56:42 2006
From: jjinux at gmail.com (Shannon -jj Behrens)
Date: Wed, 4 Oct 2006 14:56:42 -0700
Subject: [py-dev] greenlets: IO based scheduler
Message-ID: <c41f67b90610041456n6396b626t2fbb6582d5d125ed@mail.gmail.com>

I just learned about Greenlets today, and I can't seem to learn
enough.  The library as is is very nice, simple, and complete, but I'm
wondering if anyone is successfully using it for network servers yet?
Specifically, I'd like an IO-based scheduler based on Greenlets and
select.poll().  Can someone point me in the right direction?

Thanks,
-jj

-- 
The one who gets the last laugh isn't the one who did the laughing,
but rather the one who did the writing.

From mwh at python.net  Thu Oct  5 10:08:24 2006
From: mwh at python.net (Michael Hudson)
Date: Thu, 05 Oct 2006 09:08:24 +0100
Subject: [py-dev] greenlets: IO based scheduler
In-Reply-To: <c41f67b90610041456n6396b626t2fbb6582d5d125ed@mail.gmail.com>
	(Shannon's message of "Wed, 4 Oct 2006 14:56:42 -0700")
References: <c41f67b90610041456n6396b626t2fbb6582d5d125ed@mail.gmail.com>
Message-ID: <2mpsd7dw1z.fsf@starship.python.net>

"Shannon -jj Behrens" <jjinux at gmail.com> writes:

> I just learned about Greenlets today, and I can't seem to learn
> enough.  The library as is is very nice, simple, and complete, but I'm
> wondering if anyone is successfully using it for network servers yet?
> Specifically, I'd like an IO-based scheduler based on Greenlets and
> select.poll().  Can someone point me in the right direction?

There's some stuff in here:

http://codespeak.net/svn/user/arigo/hack/pypeers/

But maybe it would be best if Armin explained it (I'll be listening
too :-).

Cheers,
mwh

-- 
  <glyph> "Fetch me my internet pants."
                                                -- from Twisted.Quotes

From grig at agilistas.org  Fri Oct  6 17:05:08 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Fri, 6 Oct 2006 08:05:08 -0700
Subject: [py-dev] Running py lib unit tests in Pybots
Message-ID: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>

Hi, guys

Not sure you've seen any of my announcements on the Pybots buildbot farm (<
http://pybots.org>). I was thinking it would be cool to run the py lib unit
tests on one of the buildslaves (I can run them on one of my 2), or even
better, maybe you can contribute a buildslave :-)

In any case, let me know if you're OK with having the tests running in
Pybots.]

Grig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061006/a609f1a4/attachment.htm 

From fijal at genesilico.pl  Sun Oct  8 22:55:44 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Sun, 08 Oct 2006 22:55:44 +0200
Subject: [py-dev] [pypy-dev] py.test bug
In-Reply-To: <20061008125020.72f527e0.simon@arrowtheory.com>
References: <20061008125020.72f527e0.simon@arrowtheory.com>
Message-ID: <452965D0.8070800@genesilico.pl>

Simon Burton wrote:

>Traceback (most recent call last):
>  File "/home/simon/bin/py.test", line 4, in ?
>    py.test.cmdline.main()
>  File "/home/simon/local/pypy/py/test/cmdline.py", line 17, in main
>    failures = session.main(args)
>  File "/home/simon/local/pypy/py/test/terminal/terminal.py", line 34, in main
>    return super(TerminalSession, self).main(args)
>  File "/home/simon/local/pypy/py/test/session.py", line 52, in main
>    self.footer(colitems)
>  File "/home/simon/local/pypy/py/test/terminal/terminal.py", line 167, in footer
>    self.failures()
>  File "/home/simon/local/pypy/py/test/terminal/terminal.py", line 262, in failures
>    self.repr_failure(colitem, outcome)
>  File "/home/simon/local/pypy/py/test/terminal/terminal.py", line 280, in repr_failure
>    handler(item, excinfo, traceback)
>  File "/home/simon/local/pypy/py/test/terminal/terminal.py", line 297, in repr_failure_tblong
>    firstsourceline = entry.getfirstlinesource()
>AttributeError: 'TracebackEntry' object has no attribute 'getfirstlinesource'
>
>
>Simon.
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev
>  
>
You seem to have old version of py.test. Please update to svn trunk.


From holger at merlinux.de  Thu Oct 12 20:18:32 2006
From: holger at merlinux.de (holger krekel)
Date: Thu, 12 Oct 2006 20:18:32 +0200
Subject: [py-dev] [py-svn] r33226 - py/dist/py/test/rsession
In-Reply-To: <20061012121239.19D65101EC@code0.codespeak.net>
References: <20061012121239.19D65101EC@code0.codespeak.net>
Message-ID: <20061012181832.GE10672@solar.trillke.net>

Hi Maciej! 

what about a test for this?  At least on linux 
issuing specific "kill" commands etc. should work. 

And thinking about good ways to test such things 
helps to be confident about py.test-distributed ... 

best, 

    holger

On Thu, Oct 12, 2006 at 14:12 +0200, fijal at codespeak.net wrote:

> Author: fijal
> Date: Thu Oct 12 14:12:37 2006
> New Revision: 33226
> 
> Modified:
>    py/dist/py/test/rsession/rsession.py
> Log:
> Better signal reporting.
> 
> 
> Modified: py/dist/py/test/rsession/rsession.py
> ==============================================================================
> --- py/dist/py/test/rsession/rsession.py	(original)
> +++ py/dist/py/test/rsession/rsession.py	Thu Oct 12 14:12:37 2006
> @@ -98,7 +98,10 @@
>              host = event.channel.gateway.sshaddress
>              self.out.sep('_', "%s on %s" % 
>                  (" ".join(event.item.listnames()), host))
> -            self.repr_failure(event.item, event.outcome)
> +            if event.outcome.signal:
> +                self.repr_signal(event.item, event.outcome)
> +            else:
> +                self.repr_failure(event.item, event.outcome)
>      
>      def repr_failure(self, item, outcome): 
>          excinfo = outcome.excinfo
> @@ -117,7 +120,16 @@
>          if outcome.stderr:
>              self.out.sep('-', " Captured process stderr: ")
>              self.out.write(outcome.stderr)
> -        
> +    
> +    def repr_signal(self, item, outcome):
> +        signal = outcome.signal
> +        self.out.line("Received signal: %d" % outcome.signal)
> +        if outcome.stdout:
> +            self.out.sep('-', " Captured process stdout: ")
> +            self.out.write(outcome.stdout)
> +        if outcome.stderr:
> +            self.out.sep('-', " Captured process stderr: ")
> +            self.out.write(outcome.stderr)
>  
>      def repr_failure_tblong(self, item, excinfo, traceback):
>          for index, entry in py.builtin.enumerate(traceback): 
> _______________________________________________
> py-svn mailing list
> py-svn at codespeak.net
> http://codespeak.net/mailman/listinfo/py-svn
> 

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

From holger at merlinux.de  Thu Oct 12 20:22:27 2006
From: holger at merlinux.de (holger krekel)
Date: Thu, 12 Oct 2006 20:22:27 +0200
Subject: [py-dev] [py-svn] r33226 - py/dist/py/test/rsession
In-Reply-To: <20061012181832.GE10672@solar.trillke.net>
References: <20061012121239.19D65101EC@code0.codespeak.net>
	<20061012181832.GE10672@solar.trillke.net>
Message-ID: <20061012182227.GF10672@solar.trillke.net>

On Thu, Oct 12, 2006 at 20:18 +0200, holger krekel wrote:
> what about a test for this?  At least on linux 
> issuing specific "kill" commands etc. should work. 

hum, even testing it by calling the function
might work - which would be a better "unit" test
than firing up sub sessions etc. 

    holger
 
> And thinking about good ways to test such things 
> helps to be confident about py.test-distributed ... 
> 
> best, 
> 
>     holger
> 
> On Thu, Oct 12, 2006 at 14:12 +0200, fijal at codespeak.net wrote:
> 
> > Author: fijal
> > Date: Thu Oct 12 14:12:37 2006
> > New Revision: 33226
> > 
> > Modified:
> >    py/dist/py/test/rsession/rsession.py
> > Log:
> > Better signal reporting.
> > 
> > 
> > Modified: py/dist/py/test/rsession/rsession.py
> > ==============================================================================
> > --- py/dist/py/test/rsession/rsession.py	(original)
> > +++ py/dist/py/test/rsession/rsession.py	Thu Oct 12 14:12:37 2006
> > @@ -98,7 +98,10 @@
> >              host = event.channel.gateway.sshaddress
> >              self.out.sep('_', "%s on %s" % 
> >                  (" ".join(event.item.listnames()), host))
> > -            self.repr_failure(event.item, event.outcome)
> > +            if event.outcome.signal:
> > +                self.repr_signal(event.item, event.outcome)
> > +            else:
> > +                self.repr_failure(event.item, event.outcome)
> >      
> >      def repr_failure(self, item, outcome): 
> >          excinfo = outcome.excinfo
> > @@ -117,7 +120,16 @@
> >          if outcome.stderr:
> >              self.out.sep('-', " Captured process stderr: ")
> >              self.out.write(outcome.stderr)
> > -        
> > +    
> > +    def repr_signal(self, item, outcome):
> > +        signal = outcome.signal
> > +        self.out.line("Received signal: %d" % outcome.signal)
> > +        if outcome.stdout:
> > +            self.out.sep('-', " Captured process stdout: ")
> > +            self.out.write(outcome.stdout)
> > +        if outcome.stderr:
> > +            self.out.sep('-', " Captured process stderr: ")
> > +            self.out.write(outcome.stderr)
> >  
> >      def repr_failure_tblong(self, item, excinfo, traceback):
> >          for index, entry in py.builtin.enumerate(traceback): 
> > _______________________________________________
> > py-svn mailing list
> > py-svn at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-svn
> > 
> 
> -- 
> merlinux GmbH       Steinbergstr. 42    31139 Hildesheim   
> http://merlinux.de  tel +49 5121 20800 75 (fax 77) 
> _______________________________________________
> 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 grig at agilistas.org  Thu Oct 12 20:24:12 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Thu, 12 Oct 2006 11:24:12 -0700
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>
Message-ID: <dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>

On 10/6/06, Grig Gheorghiu <grig at agilistas.org> wrote:
>
> Hi, guys
>
> Not sure you've seen any of my announcements on the Pybots buildbot farm
> (<http://pybots.org>). I was thinking it would be cool to run the py lib
> unit tests on one of the buildslaves (I can run them on one of my 2), or
> even better, maybe you can contribute a buildslave :-)
>
> In any case, let me know if you're OK with having the tests running in
> Pybots.]
>
> Grig
>


Replying to my own post, since I haven't seen any other replies.....I assume
silence means it's OK for me to go ahead and do it :-)

Grig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061012/853fdad4/attachment.htm 

From hpk at trillke.net  Thu Oct 12 22:53:08 2006
From: hpk at trillke.net (holger krekel)
Date: Thu, 12 Oct 2006 22:53:08 +0200
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>
	<dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>
Message-ID: <20061012205308.GI10672@solar.trillke.net>

Hey Grig! 

On Thu, Oct 12, 2006 at 11:24 -0700, Grig Gheorghiu wrote:
> On 10/6/06, Grig Gheorghiu <grig at agilistas.org> wrote:
> >
> >Hi, guys
> >
> >Not sure you've seen any of my announcements on the Pybots buildbot farm
> >(<http://pybots.org>). I was thinking it would be cool to run the py lib
> >unit tests on one of the buildslaves (I can run them on one of my 2), or
> >even better, maybe you can contribute a buildslave :-)
> >
> >In any case, let me know if you're OK with having the tests running in
> >Pybots.]
> >
> >Grig

somehow i don't remember your mail - but i just looked now! 
And interesting as we are also tackling approaches for
distributing tests, buildfarms and whatnot.  Seems
to be a hot topic (and rightfully so!). 

> Replying to my own post, since I haven't seen any other replies.....I assume
> silence means it's OK for me to go ahead and do it :-)

even explicitely: go ahead and post here any problems :) 

best, 

    holger

From grig at agilistas.org  Fri Oct 13 00:32:45 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Thu, 12 Oct 2006 15:32:45 -0700
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <20061012205308.GI10672@solar.trillke.net>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>
	<dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>
	<20061012205308.GI10672@solar.trillke.net>
Message-ID: <dd49cdd20610121532k7f64e852m40aaaf6a9070b835@mail.gmail.com>

On 10/12/06, holger krekel <hpk at trillke.net> wrote:
>
> Hey Grig!
>
> On Thu, Oct 12, 2006 at 11:24 -0700, Grig Gheorghiu wrote:
> > On 10/6/06, Grig Gheorghiu <grig at agilistas.org> wrote:
> > >
> > >Hi, guys
> > >
> > >Not sure you've seen any of my announcements on the Pybots buildbot
> farm
> > >(<http://pybots.org>). I was thinking it would be cool to run the py
> lib
> > >unit tests on one of the buildslaves (I can run them on one of my 2),
> or
> > >even better, maybe you can contribute a buildslave :-)
> > >
> > >In any case, let me know if you're OK with having the tests running in
> > >Pybots.]
> > >
> > >Grig
>
> somehow i don't remember your mail - but i just looked now!
> And interesting as we are also tackling approaches for
> distributing tests, buildfarms and whatnot.  Seems
> to be a hot topic (and rightfully so!).
>
> > Replying to my own post, since I haven't seen any other replies.....I
> assume
> > silence means it's OK for me to go ahead and do it :-)
>
> even explicitely: go ahead and post here any problems :)


Great, thanks! Will do. If you guys also want to contribute a buildslave,
please let me know.

Grig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061012/52061f1e/attachment-0001.htm 

From grig at agilistas.org  Fri Oct 13 00:53:28 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Thu, 12 Oct 2006 15:53:28 -0700
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <dd49cdd20610121532k7f64e852m40aaaf6a9070b835@mail.gmail.com>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>
	<dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>
	<20061012205308.GI10672@solar.trillke.net>
	<dd49cdd20610121532k7f64e852m40aaaf6a9070b835@mail.gmail.com>
Message-ID: <dd49cdd20610121553rced54aagf3ca7a78b5d2d527@mail.gmail.com>

On 10/12/06, Grig Gheorghiu <grig at agilistas.org> wrote:
>
> On 10/12/06, holger krekel <hpk at trillke.net> wrote:
>
> > go ahead and post here any problems :)
>
>

OK, I just did an svn co of the py lib on an Ubuntu Breezy box and I get 2
failures when running py.test in the topmost directory:

________________________ entrypoint: test_importall[81]
________________________

    def check_import(modpath):
        print "checking import", modpath
>       assert __import__(modpath)

[/tmp/pylib/py/misc/testing/test_initpkg.py:67]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _

    """

    from py.__.test.rsession.web import exported_methods
E   from pypy.translator.js.modules import _dom as dom
>   ImportError: No module named pypy.translator.js.modules

[/tmp/pylib/py/test/rsession/webjs.py:6]
- - - - - - - - - - - - - -  [81]: recorded stdout - - - - - - - - - - - - -
- -
checking import py.__.test.rsession.webjs

________________________________________________________________________________
______________________ entrypoint: test_slave_main_simple
______________________

    def test_slave_main_simple():
        res = []
        q = [None,
             funcpass_spec,
             funcfail_spec
            ]
        slave_main(q.pop, res.append, str(rootdir))
        assert len(res) == 2
        res_repr = [ReprOutcome(r) for r in res]
        assert not res_repr[0].passed
E       assert res_repr[1].passed
>       assert <ReprOutcome signal=0 passed=False skipped=None
setupfailure=False excinfo=<Ex...close()\n            self.retval =
marshal.loads(retval_data)]> stdout= stderr=>.passed

[/tmp/pylib/py/test/rsession/testing/test_slave.py:110]
________________________________________________________________________________
===== tests finished: 1168 passed, 2 failed, 53 skipped in 137.70 seconds
======


Looks like the first test tries to import something from pypy, which I
haven't checked out. The second test -- not sure why it fails. Are these
failures expected?

Grig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061012/c20687fa/attachment.htm 

From cfbolz at gmx.de  Fri Oct 13 00:58:03 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Fri, 13 Oct 2006 00:58:03 +0200
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <dd49cdd20610121553rced54aagf3ca7a78b5d2d527@mail.gmail.com>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>	<dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>	<20061012205308.GI10672@solar.trillke.net>	<dd49cdd20610121532k7f64e852m40aaaf6a9070b835@mail.gmail.com>
	<dd49cdd20610121553rced54aagf3ca7a78b5d2d527@mail.gmail.com>
Message-ID: <452EC87B.9090707@gmx.de>

Grig Gheorghiu wrote:
> On 10/12/06, *Grig Gheorghiu* <grig at agilistas.org
> <mailto:grig at agilistas.org>> wrote:
> 
>     On 10/12/06, *holger krekel* <hpk at trillke.net
>     <mailto:hpk at trillke.net>> wrote:
> 
>         go ahead and post here any problems :) 
> 
> 
> 
> OK, I just did an svn co of the py lib on an Ubuntu Breezy box and I get
> 2 failures when running py.test in the topmost directory:
> 
> ________________________ entrypoint: test_importall[81]
> ________________________
> 
>     def check_import(modpath):
>         print "checking import", modpath
>>       assert __import__(modpath)
> 
> [/tmp/pylib/py/misc/testing/test_initpkg.py:67]
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _
> 
>     """
> 
>     from py.__.test.rsession.web import exported_methods
> E   from pypy.translator.js.modules import _dom as dom
>>   ImportError: No module named pypy.translator.js.modules
> 
> [/tmp/pylib/py/test/rsession/webjs.py:6]
> - - - - - - - - - - - - - -  [81]: recorded stdout - - - - - - - - - - -
> - - - -
> checking import py.__.test.rsession.webjs
> 
> ________________________________________________________________________________
> 
> ______________________ entrypoint: test_slave_main_simple
> ______________________
> 
>     def test_slave_main_simple():
>         res = []
>         q = [None,
>              funcpass_spec,
>              funcfail_spec
>             ]
>         slave_main(q.pop, res.append, str(rootdir))
>         assert len(res) == 2
>         res_repr = [ReprOutcome(r) for r in res]
>         assert not res_repr[0].passed
> E       assert res_repr[1].passed
>>       assert <ReprOutcome signal=0 passed=False skipped=None
> setupfailure=False excinfo=<Ex...close()\n            self.retval =
> marshal.loads(retval_data)]> stdout= stderr=>.passed
> 
> [/tmp/pylib/py/test/rsession/testing/test_slave.py:110]
> ________________________________________________________________________________
> ===== tests finished: 1168 passed, 2 failed, 53 skipped in 137.70
> seconds ======
> 
> 
> Looks like the first test tries to import something from pypy, which I
> haven't checked out. The second test -- not sure why it fails. Are these
> failures expected?

I don't think they are, but they might go undetected (since we all have
pypy checked out :-)). In theory the code should make sure that if pypy
is not importable it still works (maybe skipping the test or something).
Will look into it.

Thanks for the reporting!

Cheers,

Carl Friedrich

From fijal at genesilico.pl  Fri Oct 13 01:25:52 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Fri, 13 Oct 2006 01:25:52 +0200
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <dd49cdd20610121553rced54aagf3ca7a78b5d2d527@mail.gmail.com>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>	<dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>	<20061012205308.GI10672@solar.trillke.net>	<dd49cdd20610121532k7f64e852m40aaaf6a9070b835@mail.gmail.com>
	<dd49cdd20610121553rced54aagf3ca7a78b5d2d527@mail.gmail.com>
Message-ID: <452ECF00.5010707@genesilico.pl>

Grig Gheorghiu wrote:

> On 10/12/06, *Grig Gheorghiu* <grig at agilistas.org 
> <mailto:grig at agilistas.org>> wrote:
>
>     On 10/12/06, *holger krekel* <hpk at trillke.net
>     <mailto:hpk at trillke.net>> wrote:
>
>         go ahead and post here any problems :) 
>
>
>
> OK, I just did an svn co of the py lib on an Ubuntu Breezy box and I 
> get 2 failures when running py.test in the topmost directory:
>
> ________________________ entrypoint: test_importall[81] 
> ________________________
>
>     def check_import(modpath):
>         print "checking import", modpath
> >       assert __import__(modpath)
>
> [/tmp/pylib/py/misc/testing/test_initpkg.py:67]
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ _ _ _ _
>
>     """
>
>     from py.__.test.rsession.web import exported_methods
> E   from pypy.translator.js.modules import _dom as dom
> >   ImportError: No module named pypy.translator.js.modules
>
> [/tmp/pylib/py/test/rsession/webjs.py:6]
> - - - - - - - - - - - - - -  [81]: recorded stdout - - - - - - - - - - 
> - - - - -
> checking import py.__.test.rsession.webjs
>
> ________________________________________________________________________________ 
>
> ______________________ entrypoint: test_slave_main_simple 
> ______________________
>
>     def test_slave_main_simple():
>         res = []
>         q = [None,
>              funcpass_spec,
>              funcfail_spec
>             ]
>         slave_main(q.pop, res.append, str(rootdir))
>         assert len(res) == 2
>         res_repr = [ReprOutcome(r) for r in res]
>         assert not res_repr[0].passed
> E       assert res_repr[1].passed
> >       assert <ReprOutcome signal=0 passed=False skipped=None 
> setupfailure=False excinfo=<Ex...close()\n            self.retval = 
> marshal.loads(retval_data)]> stdout= stderr=>.passed
>
> [/tmp/pylib/py/test/rsession/testing/test_slave.py:110]
> ________________________________________________________________________________
> ===== tests finished: 1168 passed, 2 failed, 53 skipped in 137.70 
> seconds ======
>
>
> Looks like the first test tries to import something from pypy, which I 
> haven't checked out. The second test -- not sure why it fails. Are 
> these failures expected?
>
> Grig
>
>------------------------------------------------------------------------
>
>_______________________________________________
>py-dev mailing list
>py-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/py-dev
>  
>
Ok, first one is fixed (blame me), while the second one is a bit 
misterious for me. Can you reproduce it?

Btw: I'm quite curious about that, can we get test reports if they fail 
to py-dev mailing list?

From grig at agilistas.org  Fri Oct 13 01:57:03 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Thu, 12 Oct 2006 16:57:03 -0700
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <452ECF00.5010707@genesilico.pl>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>
	<dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>
	<20061012205308.GI10672@solar.trillke.net>
	<dd49cdd20610121532k7f64e852m40aaaf6a9070b835@mail.gmail.com>
	<dd49cdd20610121553rced54aagf3ca7a78b5d2d527@mail.gmail.com>
	<452ECF00.5010707@genesilico.pl>
Message-ID: <dd49cdd20610121657s117a256ay8d3c2c89dec5cb4d@mail.gmail.com>

On 10/12/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:
>
> Grig Gheorghiu wrote:
>
> > On 10/12/06, *Grig Gheorghiu* <grig at agilistas.org
> > <mailto:grig at agilistas.org>> wrote:
> >
> >     On 10/12/06, *holger krekel* <hpk at trillke.net
> >     <mailto:hpk at trillke.net>> wrote:
> >
> >         go ahead and post here any problems :)
> >
> >
> >
> > OK, I just did an svn co of the py lib on an Ubuntu Breezy box and I
> > get 2 failures when running py.test in the topmost directory:
> >
> > ________________________ entrypoint: test_importall[81]
> > ________________________
> >
> >     def check_import(modpath):
> >         print "checking import", modpath
> > >       assert __import__(modpath)
> >
> > [/tmp/pylib/py/misc/testing/test_initpkg.py:67]
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> > _ _ _ _ _
> >
> >     """
> >
> >     from py.__.test.rsession.web import exported_methods
> > E   from pypy.translator.js.modules import _dom as dom
> > >   ImportError: No module named pypy.translator.js.modules
> >
> > [/tmp/pylib/py/test/rsession/webjs.py:6]
> > - - - - - - - - - - - - - -  [81]: recorded stdout - - - - - - - - - -
> > - - - - -
> > checking import py.__.test.rsession.webjs
> >
> >
> ________________________________________________________________________________
> >
> > ______________________ entrypoint: test_slave_main_simple
> > ______________________
> >
> >     def test_slave_main_simple():
> >         res = []
> >         q = [None,
> >              funcpass_spec,
> >              funcfail_spec
> >             ]
> >         slave_main(q.pop, res.append, str(rootdir))
> >         assert len(res) == 2
> >         res_repr = [ReprOutcome(r) for r in res]
> >         assert not res_repr[0].passed
> > E       assert res_repr[1].passed
> > >       assert <ReprOutcome signal=0 passed=False skipped=None
> > setupfailure=False excinfo=<Ex...close()\n            self.retval =
> > marshal.loads(retval_data)]> stdout= stderr=>.passed
> >
> > [/tmp/pylib/py/test/rsession/testing/test_slave.py:110]
> >
> ________________________________________________________________________________
> > ===== tests finished: 1168 passed, 2 failed, 53 skipped in 137.70
> > seconds ======
> >
> >
> > Looks like the first test tries to import something from pypy, which I
> > haven't checked out. The second test -- not sure why it fails. Are
> > these failures expected?
> >
> > Grig
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >py-dev mailing list
> >py-dev at codespeak.net
> >http://codespeak.net/mailman/listinfo/py-dev
> >
> >
> Ok, first one is fixed (blame me), while the second one is a bit
> misterious for me. Can you reproduce it?



I just enabled the testing of py.test on one of my Pybots buildslaves. The
current Pybots build farm is here:

http://www.python.org/dev/buildbot/community/all/

There are 2 tests that fail (the pypy one was fixed). See the output here:

http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/34/step-py.test/0

Btw: I'm quite curious about that, can we get test reports if they fail
> to py-dev mailing list?
>


I'm working on getting email notifications to work from the buildmaster,
which is hosted on python.org -- and there are some issues with outgoing
email from there. As soon as I solve this issue, I'll configure the
buildmaster so it sends notifications on py.test failures to this mailing
list.

Grig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061012/f92a5ace/attachment.htm 

From fijal at genesilico.pl  Fri Oct 13 02:27:02 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Fri, 13 Oct 2006 02:27:02 +0200
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <dd49cdd20610121657s117a256ay8d3c2c89dec5cb4d@mail.gmail.com>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>	
	<dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>	
	<20061012205308.GI10672@solar.trillke.net>	
	<dd49cdd20610121532k7f64e852m40aaaf6a9070b835@mail.gmail.com>	
	<dd49cdd20610121553rced54aagf3ca7a78b5d2d527@mail.gmail.com>	
	<452ECF00.5010707@genesilico.pl>
	<dd49cdd20610121657s117a256ay8d3c2c89dec5cb4d@mail.gmail.com>
Message-ID: <452EDD56.6090500@genesilico.pl>

Grig Gheorghiu wrote:

> On 10/12/06, *Maciek Fijalkowski* <fijal at genesilico.pl 
> <mailto:fijal at genesilico.pl>> wrote:
>
>     Grig Gheorghiu wrote:
>
>     > On 10/12/06, *Grig Gheorghiu* <grig at agilistas.org
>     <mailto:grig at agilistas.org>
>     > <mailto:grig at agilistas.org <mailto:grig at agilistas.org>>> wrote:
>     >
>     >     On 10/12/06, *holger krekel* <hpk at trillke.net
>     <mailto:hpk at trillke.net>
>     >     <mailto:hpk at trillke.net <mailto:hpk at trillke.net>>> wrote:
>     >
>     >         go ahead and post here any problems :)
>     >
>     >
>     >
>     > OK, I just did an svn co of the py lib on an Ubuntu Breezy box and I
>     > get 2 failures when running py.test in the topmost directory:
>     >
>     > ________________________ entrypoint: test_importall[81]
>     > ________________________
>     >
>     >     def check_import(modpath):
>     >         print "checking import", modpath
>     > >       assert __import__(modpath)
>     >
>     > [/tmp/pylib/py/misc/testing/test_initpkg.py:67]
>     > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>     _ _ _
>     > _ _ _ _ _
>     >
>     >     """
>     >
>     >     from py.__.test.rsession.web import exported_methods
>     > E   from pypy.translator.js.modules import _dom as dom
>     > >   ImportError: No module named pypy.translator.js.modules
>     >
>     > [/tmp/pylib/py/test/rsession/webjs.py:6]
>     > - - - - - - - - - - - - - -  [81]: recorded stdout - - - - - - -
>     - - -
>     > - - - - -
>     > checking import py.__.test.rsession.webjs
>     >
>     >
>     ________________________________________________________________________________
>     >
>     > ______________________ entrypoint: test_slave_main_simple
>     > ______________________
>     >
>     >     def test_slave_main_simple():
>     >         res = []
>     >         q = [None,
>     >              funcpass_spec,
>     >              funcfail_spec
>     >             ]
>     >         slave_main(q.pop, res.append, str(rootdir))
>     >         assert len(res) == 2
>     >         res_repr = [ReprOutcome(r) for r in res]
>     >         assert not res_repr[0].passed
>     > E       assert res_repr[1].passed
>     > >       assert <ReprOutcome signal=0 passed=False skipped=None
>     > setupfailure=False excinfo=<Ex...close()\n            self.retval =
>     > marshal.loads(retval_data)]> stdout= stderr=>.passed
>     >
>     > [/tmp/pylib/py/test/rsession/testing/test_slave.py:110]
>     >
>     ________________________________________________________________________________
>     > ===== tests finished: 1168 passed, 2 failed, 53 skipped in 137.70
>     > seconds ======
>     >
>     >
>     > Looks like the first test tries to import something from pypy,
>     which I
>     > haven't checked out. The second test -- not sure why it fails. Are
>     > these failures expected?
>     >
>     > Grig
>     >
>     >------------------------------------------------------------------------
>     >
>     >_______________________________________________
>     >py-dev mailing list
>     > py-dev at codespeak.net <mailto:py-dev at codespeak.net>
>     >http://codespeak.net/mailman/listinfo/py-dev
>     >
>     >
>     Ok, first one is fixed (blame me), while the second one is a bit
>     misterious for me. Can you reproduce it?
>
>
>
> I just enabled the testing of py.test on one of my Pybots buildslaves. 
> The current Pybots build farm is here:
>
> http://www.python.org/dev/buildbot/community/all/
>
> There are 2 tests that fail (the pypy one was fixed). See the output here:
>
> http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/34/step-py.test/0
>
>     Btw: I'm quite curious about that, can we get test reports if they
>     fail
>     to py-dev mailing list?
>
>
>
> I'm working on getting email notifications to work from the 
> buildmaster, which is hosted on python.org <http://python.org> -- and 
> there are some issues with outgoing email from there. As soon as I 
> solve this issue, I'll configure the buildmaster so it sends 
> notifications on py.test failures to this mailing list.
>
> Grig

The both tests look serious, altough I do not know how to reproduce them 
(they do not fail for me). Can I get access to the machine or maybe a 
(detailed) list of packages installed and such?

If I can reproduce the errors, I'll try to fix them.

But it's 2:30 AM  for me, so not today...


From grig at agilistas.org  Fri Oct 13 02:50:00 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Thu, 12 Oct 2006 17:50:00 -0700
Subject: [py-dev] Running py lib unit tests in Pybots
In-Reply-To: <452EDD56.6090500@genesilico.pl>
References: <dd49cdd20610060805l16d7cc00v23550983c936193f@mail.gmail.com>
	<dd49cdd20610121124g1164c293vde41e3c99f5472c4@mail.gmail.com>
	<20061012205308.GI10672@solar.trillke.net>
	<dd49cdd20610121532k7f64e852m40aaaf6a9070b835@mail.gmail.com>
	<dd49cdd20610121553rced54aagf3ca7a78b5d2d527@mail.gmail.com>
	<452ECF00.5010707@genesilico.pl>
	<dd49cdd20610121657s117a256ay8d3c2c89dec5cb4d@mail.gmail.com>
	<452EDD56.6090500@genesilico.pl>
Message-ID: <dd49cdd20610121750x30037568ie63be57fcc4e3360@mail.gmail.com>

On 10/12/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:
>
> > I just enabled the testing of py.test on one of my Pybots buildslaves.
> > The current Pybots build farm is here:
> >
> > http://www.python.org/dev/buildbot/community/all/
> >
> > There are 2 tests that fail (the pypy one was fixed). See the output
> here:
> >
> >
> http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/34/step-py.test/0
> >
> The both tests look serious, altough I do not know how to reproduce them
> (they do not fail for me). Can I get access to the machine or maybe a
> (detailed) list of packages installed and such?
>
> If I can reproduce the errors, I'll try to fix them.
>
> But it's 2:30 AM  for me, so not today...
>
>
I seem to remember that some execnet tests used to fail for me on some
platforms, kind of randomly. As for the other test (test_slave.py), I'm not
sure what's going on. If you can't reproduce these failures on any other
boxes you have, I'll let you have access on my box.

Grig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061012/6f636fc5/attachment.htm 

From grig at agilistas.org  Fri Oct 13 03:13:46 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Thu, 12 Oct 2006 18:13:46 -0700
Subject: [py-dev] py lib tests are passing on pybots buildslave
Message-ID: <dd49cdd20610121813j5f9083dbn387e5d02b8ed575f@mail.gmail.com>

On 10/12/06, Grig Gheorghiu <grig at agilistas.org> wrote:
>
> On 10/12/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:
> >
> > How recent your checkout is? I think I've fixed those problems (at least
> > one) like yesterday or so.
> >
>
>
> I delete the original directory, then I do a fresh checkout every time I
> test. It may be a platform-specific issue.
>
> Grig
>


OK, now all tests are passing.

http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/35/step-py.lib/0

Grig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061012/f9fb61fb/attachment.htm 

From fijal at genesilico.pl  Fri Oct 13 09:21:32 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Fri, 13 Oct 2006 09:21:32 +0200
Subject: [py-dev] py lib tests are passing on pybots buildslave
In-Reply-To: <dd49cdd20610121813j5f9083dbn387e5d02b8ed575f@mail.gmail.com>
References: <dd49cdd20610121813j5f9083dbn387e5d02b8ed575f@mail.gmail.com>
Message-ID: <452F3E7C.70400@genesilico.pl>

Grig Gheorghiu wrote:

> On 10/12/06, *Grig Gheorghiu* <grig at agilistas.org 
> <mailto:grig at agilistas.org>> wrote:
>
>     On 10/12/06, *Maciek Fijalkowski* <fijal at genesilico.pl
>     <mailto:fijal at genesilico.pl>> wrote:
>
>         How recent your checkout is? I think I've fixed those problems
>         (at least
>         one) like yesterday or so.
>
>
>
>     I delete the original directory, then I do a fresh checkout every
>     time I test. It may be a platform-specific issue.
>
>     Grig
>
>
>
> OK, now all tests are passing.
>
> http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/35/step-py.lib/0 
> <http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/35/step-py.lib/0>
>
> Grig

Cool.

I suspect .pyc files or so...


From holger at merlinux.de  Mon Oct 16 23:30:07 2006
From: holger at merlinux.de (holger krekel)
Date: Mon, 16 Oct 2006 23:30:07 +0200
Subject: [py-dev] [py-svn] r33350 - in py/dist/py: . code test/rsession
In-Reply-To: <20061016204908.64B5A10068@code0.codespeak.net>
References: <20061016204908.64B5A10068@code0.codespeak.net>
Message-ID: <20061016213007.GX10672@solar.trillke.net>

Hi Maciej, 


On Mon, Oct 16, 2006 at 22:49 +0200, fijal at codespeak.net wrote:

> Author: fijal
> Date: Mon Oct 16 22:48:34 2006
> New Revision: 33350
> 
> Modified:
>    py/dist/py/__init__.py
>    py/dist/py/code/excinfo.py
>    py/dist/py/code/traceback2.py

could you add tests for this within py/code (not indirectly
through some py/test/rsession code)?  

best, 

    holger

From arigo at tunes.org  Sun Oct 22 21:03:53 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 22 Oct 2006 21:03:53 +0200
Subject: [py-dev] greenlets pickle support
In-Reply-To: <2af4014d0610200212h745ec9a7uc4290aeb4bc5af1c@mail.gmail.com>
References: <2af4014d0610200212h745ec9a7uc4290aeb4bc5af1c@mail.gmail.com>
Message-ID: <20061022190353.GB24285@code0.codespeak.net>

Hello,

On Fri, Oct 20, 2006 at 11:12:17AM +0200, Paolo Losi wrote:
> I'm looking at greenlets for a workflow engine project.
> It would be nice if greenlets execution state could be persisted
> via cPickle. Is pickle support planned / easy to implement?

Not at all.  To get this you need the full Stackless Python - or PyPy
:-)  But there is no way I can think of to make greenlet pickling even
remotely realizable.


A bientot,

Armin

From fijal at genesilico.pl  Sun Oct 22 22:39:30 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Sun, 22 Oct 2006 22:39:30 +0200
Subject: [py-dev] Note
Message-ID: <453BD702.2010002@genesilico.pl>

not to forget...

When writing tests for LSession/RSession and friends, there are two 
States of setups, one in tests and one in testing utility itself. They 
badly interfere (like setup_module called few times). I don't know if 
it's a bug or whatever. I can propose several things:
1. Not use setup_* in those tests (this is done by now)
2. Make sure that setup_module is never introduced twice for the same 
module (as a warning or whatever) - I think it's easy to implement and 
quite usefull, but still you cannot use two states
3. Make somehow two possible states - one for testing, one for running 
test suite, altough it's hard to do.

From elmo13 at jippii.fi  Mon Oct 23 01:56:33 2006
From: elmo13 at jippii.fi (=?UTF-8?B?RWxtbyBNw6RudHluZW4=?=)
Date: Mon, 23 Oct 2006 02:56:33 +0300
Subject: [py-dev] Global state
Message-ID: <453C0531.2000401@jippii.fi>

The tested code interfaces with hardware, so I have to share a handle
between tests which I wouldn't want to confine to a single module. I
used to share state by importing a common module from the test_modules,
but after updating pylib, even skipping every test but one doesn't seem
to work. It might be my fault, but I'd like to know what I should've
been doing so I can test who is really at fault.


Elmo

From hpk at trillke.net  Mon Oct 23 08:26:37 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 23 Oct 2006 08:26:37 +0200
Subject: [py-dev] Note
In-Reply-To: <453BD702.2010002@genesilico.pl>
References: <453BD702.2010002@genesilico.pl>
Message-ID: <20061023062637.GJ10672@solar.trillke.net>

On Sun, Oct 22, 2006 at 22:39 +0200, Maciek Fijalkowski wrote:
> not to forget...
> 
> When writing tests for LSession/RSession and friends, there are two 
> States of setups, one in tests and one in testing utility itself. They 
> badly interfere (like setup_module called few times). I don't know if 
> it's a bug or whatever. I can propose several things:
> 1. Not use setup_* in those tests (this is done by now)
> 2. Make sure that setup_module is never introduced twice for the same 
> module (as a warning or whatever) - I think it's easy to implement and 
> quite usefull, but still you cannot use two states
> 3. Make somehow two possible states - one for testing, one for running 
> test suite, altough it's hard to do.

can you give a more concrete example of what goes bad? 

    holger

From grig at agilistas.org  Thu Oct 26 23:20:33 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Thu, 26 Oct 2006 14:20:33 -0700
Subject: [py-dev] py lib tests fail in Pybots buildbot
Message-ID: <dd49cdd20610261420r4b8c0363ieee0c7e3f8619d87@mail.gmail.com>

Noticed some new failures.

Full log for build step with Python trunk binary:

http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/63/step-py.lib/0

Full log for build step with Python 2.5 binary:

http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%202.5/builds/33/step-py.lib/0

Here are the errors from the 2.5 build step:

_________________ entrypoint: TestRest().test_class_typedefs __________________

    def test_class_typedefs(self):
        class A(object):
            def __init__(self, x):
                pass

        class B(object):
            def __init__(self, y):
                pass

        def xxx(x):
            return x

        descs = {'A':A, 'B':B, 'xxx':xxx}
        ds = DocStorage().from_dict(descs)
        t = Tracer(ds)
        t.start_tracing()
        xxx(A(3))
        xxx(B("f"))
        t.end_tracing()
        lg = DirectPaste()
        tempdir = temppath.ensure("classargs", dir=True)
        r = RestGen(ds, lg, DirWriter(tempdir))
>       r.write()

[/tmp/pylib/py/apigen/rest/testing/test_rest.py:285]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def write(self):
        """write the data to the writer"""
        # note that this builds up a list of Rest elements for the index as
        # 'side effect', the list is passed along and filled, while the actual
        # sections (also ReST elements) are returned by the write_* methods
        # XXX this is quite icky! would be nice to have refactored
        indexlst = [Title("Module: %s" % self.dsa.get_module_name(),
                          belowchar="="),
                    Paragraph(self.dsa.get_module_info()),
                    Title("Exported functions:", belowchar="-")]
        funclst = self.write_function_list(indexlst)
        indexlst.append(Title("Exported classes:", belowchar="-"))
>       classlst = self.write_class_list(indexlst)

[/tmp/pylib/py/apigen/rest/genrest.py:128]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def write_class_list(self, indexlst):
        retlst = []
        for name in self.dsa.get_class_names():
            sectionname = 'class_%s' % (name,)
            linktarget = self.writer.getlink('class', name, sectionname)
            indexlst.append(ListItem(Text("Class: "), Link(name, linktarget)))
>           retlst.append((sectionname, self.write_class(sectionname, name)))

[/tmp/pylib/py/apigen/rest/genrest.py:157]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def write_class(self, section_name, class_name):
        classlst = [Title("Class: %s" % class_name, belowchar='-'),
                    LiteralBlock(self.dsa.get_function_doc(class_name))]

        # write down exported methods
        classlst.append(Title("Exported methods:", belowchar="^"))
        funclist = []
        for method in self.dsa.get_class_methods(class_name):
            sectionname = 'method_%s_%s' % (class_name, method)
            linktext = '%s.%s' % (class_name, method)
            linktarget = self.writer.getlink('function', linktext,
                                                  sectionname)
            classlst.append(ListItem(Link(linktext, linktarget)))
            # XXX assuming a function is always part of a class section
            funclist.append((sectionname,
                             self.write_function(sectionname,
                                                 class_name + "." + method,
>                                                '^')))

[/tmp/pylib/py/apigen/rest/genrest.py:177]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def write_function(self, section_name, fun_name, belowchar='-'):
        # XXX I think the docstring should either be split on \n\n and cleaned
        # from indentation, or treated as ReST too (although this is obviously
        # dangerous for non-ReST docstrings)...
        lst = [Title("Function: %s" % fun_name, belowchar=belowchar),
               LiteralBlock(self.dsa.get_function_doc(fun_name)),
               LiteralBlock(self.dsa.get_function_definition(fun_name))]


        args, retval = self.dsa.get_function_signature(fun_name)
        arg_str = "\n".join(["%s :: %s" % (str(name), str(type)) for
name, type in args])
        arg_str += "\n" + "Return value :: %s" % str(retval)
        lst.append(Paragraph("where:"))
        lst.append(LiteralBlock(arg_str))

        # XXX missing implementation of dsa.get_function_location()
        #filename, lineno = self.dsa.get_function_location(fun_name)
        #linkname, linktarget = self.linkgen.getlink(filename, lineno)
        #if linktarget:
        #    lst.append(Paragraph("Function source: ",
        #               Link(linkname, linktarget)))
        #else:
        lst.append(Paragraph('Function source:'))
>       lst.append(LiteralBlock(self.dsa.get_function_source(fun_name)))

[/tmp/pylib/py/apigen/rest/genrest.py:203]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def get_function_source(self, name):
        desc = self.ds.descs[name]
        try:
>           return str(py.code.Source(desc.pyobj))

[/tmp/pylib/py/apigen/tracer/docstorage.py:196]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def __init__(self, *parts, **kwargs):
        self.lines = lines = []
        de = kwargs.get('deindent', True)
        rstrip = kwargs.get('rstrip', True)
        for part in parts:
            if not part:
                partlines = []
            if isinstance(part, Source):
                partlines = part.lines
            elif isinstance(part, (unicode, str)):
                partlines = part.split('\n')
                if rstrip:
                    while partlines:
                        if partlines[-1].strip():
                            break
                        partlines.pop()
            else:
>               partlines = getsource(part, deindent=de).lines

[/tmp/pylib/py/code/source.py:30]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def getsource(obj, **kwargs):
        if hasattr(obj, 'func_code'):
            obj = obj.func_code
        elif hasattr(obj, 'f_code'):
            obj = obj.f_code
        try:
            fullsource = obj.co_filename.__source__
        except AttributeError:
>           strsrc = inspect.getsource(obj)

[/tmp/pylib/py/code/source.py:231]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def getsource(object):
        """Return the text of the source code for an object.

        The argument may be a module, class, method, function, traceback, frame,
        or code object.  The source code is returned as a single string.  An
        IOError is raised if the source code cannot be retrieved."""
>       lines, lnum = getsourcelines(object)

[/usr/lib/python2.4/inspect.py:563]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def getsourcelines(object):
        """Return a list of source lines and starting line number for an object.

        The argument may be a module, class, method, function, traceback, frame,
        or code object.  The source code is returned as a list of the lines
        corresponding to the object and the line number indicates where in the
        original source file the first line of code was found.  An IOError is
        raised if the source code cannot be retrieved."""
        lines, lnum = findsource(object)

        if ismodule(object): return lines, 0
>       else: return getblock(lines[lnum:]), lnum + 1

[/usr/lib/python2.4/inspect.py:555]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def getblock(lines):
        """Extract the block of code at the top of the given list of lines."""
        try:
>           tokenize.tokenize(ListReader(lines).readline, BlockFinder().tokeneater)

[/usr/lib/python2.4/inspect.py:538]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def tokenize(readline, tokeneater=printtoken):
        """
        The tokenize() function accepts two parameters: one representing the
        input stream, and one providing an output mechanism for tokenize().

        The first parameter, readline, must be a callable object which provides
        the same interface as the readline() method of built-in file objects.
        Each call to the function should return one line of input as a string.

        The second parameter, tokeneater, must also be a callable object. It is
        called once for each token, with five arguments, corresponding to the
        tuples generated by generate_tokens().
        """
        try:
>           tokenize_loop(readline, tokeneater)

[/usr/lib/python2.4/tokenize.py:153]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def tokenize_loop(readline, tokeneater):
>       for token_info in generate_tokens(readline):

[/usr/lib/python2.4/tokenize.py:159]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

    def generate_tokens(readline):
        """
        The generate_tokens() generator requires one argment, readline, which
        must be a callable object which provides the same interface as the
        readline() method of built-in file objects. Each call to the function
        should return one line of input as a string.

        The generator produces 5-tuples with these members: the token type; the
        token string; a 2-tuple (srow, scol) of ints specifying the row and
        column where the token begins in the source; a 2-tuple (erow, ecol) of
        ints specifying the row and column where the token ends in the source;
        and the line on which the token was found. The line passed is the
        logical line; continuation lines are included.
        """
        lnum = parenlev = continued = 0
        namechars, numchars = string.ascii_letters + '_', '0123456789'
        contstr, needcont = '', 0
        contline = None
        indents = [0]

        while 1:                                   # loop over lines in stream
            line = readline()
            lnum = lnum + 1
            pos, max = 0, len(line)

            if contstr:                            # continued string
                if not line:
                    raise TokenError, ("EOF in multi-line string", strstart)
                endmatch = endprog.match(line)
                if endmatch:
                    pos = end = endmatch.end(0)
                    yield (STRING, contstr + line[:end],
                               strstart, (lnum, end), contline + line)
                    contstr, needcont = '', 0
                    contline = None
                elif needcont and line[-2:] != '\\\n' and line[-3:] != '\\\r\n':
                    yield (ERRORTOKEN, contstr + line,
                               strstart, (lnum, len(line)), contline)
                    contstr = ''
                    contline = None
                    continue
                else:
                    contstr = contstr + line
                    contline = contline + line
                    continue

            elif parenlev == 0 and not continued:  # new statement
                if not line: break
                column = 0
                while pos < max:                   # measure leading whitespace
                    if line[pos] == ' ': column = column + 1
                    elif line[pos] == '\t': column = (column/tabsize +
1)*tabsize
                    elif line[pos] == '\f': column = 0
                    else: break
                    pos = pos + 1
                if pos == max: break

                if line[pos] in '#\r\n':           # skip comments or
blank lines
                    yield ((NL, COMMENT)[line[pos] == '#'], line[pos:],
                               (lnum, pos), (lnum, len(line)), line)
                    continue

                if column > indents[-1]:           # count indents or dedents
                    indents.append(column)
                    yield (INDENT, line[:pos], (lnum, 0), (lnum, pos), line)
                while column < indents[-1]:
                    if column not in indents:
E                       raise IndentationError(
                            "unindent does not match any outer
indentation level")
>                       IndentationError: unindent does not match any outer indentation level

[/usr/lib/python2.4/tokenize.py:229]
_______________________________________________________________________________
______ entrypoint: TestPopenGateway().test_channel_passing_over_channel _______

    def test_channel_passing_over_channel(self):
        channel = self.gw.remote_exec('''
                        c = channel.gateway.newchannel()
                        channel.send(c)
                        c.send(42)
                      ''')
        c = channel.receive()
        x = c.receive()
        assert x == 42

        # check that the both sides previous channels are really gone
        channel.waitclose(0.3)
E       assert channel.id not in self.gw.channelfactory._channels
>       AssertionError: (inconsistently failed then succeeded)

[/tmp/pylib/py/execnet/testing/test_gateway.py:160]
_______________________________________________________________________________
_______________________ entrypoint: test_importall[226] _______________________

    def check_import(modpath):
        print "checking import", modpath
E       assert __import__(modpath)
>       ImportError: No module named package.submodule.__init__

[/tmp/pylib/py/misc/testing/test_initpkg.py:67]
- - - - - - - - - - - - -  [226]: recorded stdout - - - - - - - - - - - - - -
checking import py.__.apigen.tracer.testing.package.submodule.__init__

_______________________________________________________________________________
_______________________ entrypoint: test_importall[227] _______________________

    def check_import(modpath):
        print "checking import", modpath
E       assert __import__(modpath)
>       ImportError: No module named package.submodule.pak.__init__

[/tmp/pylib/py/misc/testing/test_initpkg.py:67]
- - - - - - - - - - - - -  [227]: recorded stdout - - - - - - - - - - - - - -
checking import py.__.apigen.tracer.testing.package.submodule.pak.__init__

_______________________________________________________________________________
_______________________ entrypoint: test_importall[228] _______________________

    def check_import(modpath):
        print "checking import", modpath
E       assert __import__(modpath)
>       ImportError: No module named package.submodule.pak.mod

[/tmp/pylib/py/misc/testing/test_initpkg.py:67]
- - - - - - - - - - - - -  [228]: recorded stdout - - - - - - - - - - - - - -
checking import py.__.apigen.tracer.testing.package.submodule.pak.mod

_______________________________________________________________________________
===== tests finished: 1256 passed, 5 failed, 55 skipped in 154.12 seconds =====
inserting into sys.path: /tmp/pylib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061026/79a1c53d/attachment-0001.htm 

From fijal at genesilico.pl  Fri Oct 27 15:51:01 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Fri, 27 Oct 2006 15:51:01 +0200
Subject: [py-dev] py lib tests fail in Pybots buildbot
In-Reply-To: <dd49cdd20610261420r4b8c0363ieee0c7e3f8619d87@mail.gmail.com>
References: <dd49cdd20610261420r4b8c0363ieee0c7e3f8619d87@mail.gmail.com>
Message-ID: <45420EC5.8000407@genesilico.pl>

Thanks. I've fixed one of the errors, 3 to fix and one which I cannot
reproduce. Just for the interest: are there more than one projects which
involve py.test on pybots?


From grig at agilistas.org  Fri Oct 27 17:52:32 2006
From: grig at agilistas.org (Grig Gheorghiu)
Date: Fri, 27 Oct 2006 08:52:32 -0700
Subject: [py-dev] py lib tests fail in Pybots buildbot
In-Reply-To: <45420EC5.8000407@genesilico.pl>
References: <dd49cdd20610261420r4b8c0363ieee0c7e3f8619d87@mail.gmail.com>
	<45420EC5.8000407@genesilico.pl>
Message-ID: <dd49cdd20610270852v49a5d944qf960e98d5ee04363@mail.gmail.com>

On 10/27/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:
>
> Thanks. I've fixed one of the errors, 3 to fix and one which I cannot
> reproduce. Just for the interest: are there more than one projects which
> involve py.test on pybots?
>
>

I only have one machine running the py lib tests. It's running Ubuntu
Breezy. If you guys can contribute some more machines, I'd be happy to work
with you in configuring buildbot on them so they can be part of the Pybots
farm.

Grig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/py-dev/attachments/20061027/e01992ec/attachment.htm 

From santoshphilip at mac.com  Sun Nov 12 06:58:06 2006
From: santoshphilip at mac.com (Santosh Philip)
Date: Sat, 11 Nov 2006 21:58:06 -0800
Subject: [py-dev] User defined exception - py.testing
Message-ID: <332851639ed9f5380744455dbf9f7090@mac.com>

I am having some trouble with testing user defined exceptions
==============
this one works
------------
def anexception(arg):
     """just raise an exception with ValueError"""
     if arg == 5:
         raise ValueError, 'Just a ValueError'

def test_anexception():
     """py.test for anexception"""
     import py.test
     py.test.raises(ValueError, anexception, 5)

===============
this one does not work
---------------
class MyError(Exception):
     """pass"""
     pass

def anotherexception(arg):
     """just raise an exception with ValueError"""
     if arg == 5:
         raise MyError, 'its a MyError'

def test_anotherexception():
     """py.test for anotherexception"""
     import py.test
     py.test.raises(ValueError, anotherexception, 5)
================

Are test for user defined exceptions working in py.test
or
Am I doing something wrong ?

when it doesn't work, the output looks like

MacBook:~/Documents/doe2python_DSU santosh$ py.test doesntwork.py
inserting into sys.path:  
/Users/santosh/Documents/coolshadowprojects/pydottest/py-dist
============================= test process starts  
==============================
testing-mode: inprocess
executable:    
/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/ 
Contents/MacOS/Python  (2.4.3-final-0)
using py lib:  
/Users/santosh/Documents/coolshadowprojects/pydottest/py-dist/py <rev  
31477>

doesntwork.py[1] F

________________________________________________________________________ 
________
______________________ entrypoint: test_anotherexception  
_______________________

     def test_anotherexception():
         """py.test for anotherexception"""
         import py.test
 >       py.test.raises(ValueError, anotherexception, 5)

[/Users/santosh/Documents/doe2python_DSU/doesntwork.py:13]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  
_ _ _ _

     def anotherexception(arg):
         """just raise an exception with ValueError"""
         if arg == 5:
E           raise MyError, 'its a MyError'
 >           MyError: its a MyError

[/Users/santosh/Documents/doe2python_DSU/doesntwork.py:8]
________________________________________________________________________ 
________
=================== tests finished: 1 failed in 0.02 seconds  
===================

thanks

Santosh


From cfbolz at gmx.de  Sun Nov 12 09:26:35 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sun, 12 Nov 2006 09:26:35 +0100
Subject: [py-dev] User defined exception - py.testing
In-Reply-To: <332851639ed9f5380744455dbf9f7090@mac.com>
References: <332851639ed9f5380744455dbf9f7090@mac.com>
Message-ID: <4556DABB.8080603@gmx.de>

Hi Santosh!

Santosh Philip wrote:
> I am having some trouble with testing user defined exceptions
> ==============
> this one works
> ------------
> def anexception(arg):
>      """just raise an exception with ValueError"""
>      if arg == 5:
>          raise ValueError, 'Just a ValueError'
>
> def test_anexception():
>      """py.test for anexception"""
>      import py.test
>      py.test.raises(ValueError, anexception, 5)
>
> ===============
> this one does not work
> ---------------
> class MyError(Exception):
>      """pass"""
>      pass
>
> def anotherexception(arg):
>      """just raise an exception with ValueError"""
>      if arg == 5:
>          raise MyError, 'its a MyError'
>
> def test_anotherexception():
>      """py.test for anotherexception"""
>      import py.test
>      py.test.raises(ValueError, anotherexception, 5)
> ================
                      ^^^^^^^^^^
Shouldn't this be "MyError"?

Btw: you don't need to say "import py.test". Just saying "import py"
is enough (py.test will be loaded only when it is used).

Cheers,

Carl Friedrich
 _______________________________________________

From fijal at genesilico.pl  Tue Nov 14 00:49:57 2006
From: fijal at genesilico.pl (=?ISO-8859-2?Q?Maciek_Fija=C5=82kowski?=)
Date: Tue, 14 Nov 2006 00:49:57 +0100 (CET)
Subject: [py-dev] py lib API
Message-ID: <Pine.LNX.4.58.0611140049450.14648@martini.genesilico.pl>

I've created some experimental API of pylib (automatically generated).

It's very rough by now, so don't expect fancy CSS and JS (at least now),
but I'm very interested in any feedback about contents.

http://codespeak.net/~fijal/output/

Cheers,
Fijal




From prouleau001 at gmail.com  Tue Nov 14 20:52:11 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Tue, 14 Nov 2006 14:52:11 -0500
Subject: [py-dev] Speed of py.test compared to unittest
Message-ID: <5c1d522d0611141152y34d19b92o486e40c03188a904@mail.gmail.com>

Hi all!

I'v just started looking into py.test.  I really like it: it's easier
to use and requires less boiler plate code than unittest.  Thanks!

However, i found that it runs much slower than unittest (at least
under some conditions).  I was expecting a slowdown because of
py.test's nature, but I get results that are 10 to 30 times slower.

I ran a test of a simple application that converts roman numeral to
integer and vice versa (taken from Mike Pilgrim's
http://diveintopython.org/ ).
In a test that checks all 4999 possible numbers, unittest performs in
about 125 mSeconds, while py.test takes about 3.8 seconds.  That's 30
times slower.
The unittest and py.test driven scripts perform the same tests.

Is this what I should expect?

I am running Python 2.4.3 on Win32 machine with py-dist revision 34574
(the latest) from svn.

Thanks,

Pierre Rouleau

From fijal at genesilico.pl  Tue Nov 14 21:34:36 2006
From: fijal at genesilico.pl (=?ISO-8859-2?Q?Maciek_Fija=C5=82kowski?=)
Date: Tue, 14 Nov 2006 21:34:36 +0100 (CET)
Subject: [py-dev] Speed of py.test compared to unittest
Message-ID: <Pine.LNX.4.58.0611142133520.20193@martini.genesilico.pl>


Pierre Rouleau wrote:

>Hi all!
>
>I'v just started looking into py.test.  I really like it: it's easier
>to use and requires less boiler plate code than unittest.  Thanks!
>
>However, i found that it runs much slower than unittest (at least
>under some conditions).  I was expecting a slowdown because of
>py.test's nature, but I get results that are 10 to 30 times slower.
>
>I ran a test of a simple application that converts roman numeral to
>integer and vice versa (taken from Mike Pilgrim's
>http://diveintopython.org/ ).
>In a test that checks all 4999 possible numbers, unittest performs in
>about 125 mSeconds, while py.test takes about 3.8 seconds.  That's 30
>times slower.
>The unittest and py.test driven scripts perform the same tests.
>
>Is this what I should expect?
>
>I am running Python 2.4.3 on Win32 machine with py-dist revision 34574
>(the latest) from svn.
>
>Thanks,
>
>Pierre Rouleau
>_______________________________________________
>py-dev mailing list
>py-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/py-dev
>
>
I would be happy to run some performance tests on my machine and
profiling as well. Please send to me some details (how to access the
code ie.). Please also note that a lot of time from that 3.8s is startup
time (I guess it's not too much pain to just allow it to be about 2s).



From prouleau001 at gmail.com  Tue Nov 14 22:36:20 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Tue, 14 Nov 2006 16:36:20 -0500
Subject: [py-dev] Fwd:  Speed of py.test compared to unittest
In-Reply-To: <5c1d522d0611141318t6f224884p80ec1c91c4e8f327@mail.gmail.com>
References: <Pine.LNX.4.58.0611142133520.20193@martini.genesilico.pl>
	<5c1d522d0611141304u42ebd283j5828a720621ec5d6@mail.gmail.com>
	<Pine.LNX.4.58.0611142209370.20415@martini.genesilico.pl>
	<5c1d522d0611141318t6f224884p80ec1c91c4e8f327@mail.gmail.com>
Message-ID: <5c1d522d0611141336v216cff28s15b9a004cb5276@mail.gmail.com>

---------- Forwarded message ----------
From: Pierre Rouleau <prouleau001 at gmail.com>
Date: Nov 14, 2006 4:18 PM
Subject: Re: [py-dev] Speed of py.test compared to unittest
To: Maciek Fija??kowski <fijal at genesilico.pl>


On 11/14/06, Maciek Fija??kowski <fijal at genesilico.pl> wrote:
>
> Sure. Please do.
>
Oh, also, as far as startup time is concerned, even though the startup
time might be constant, a larger startup time will mask differences in
execution time of the code under test.  Since a unit test system
should optimally be used during development, a startup time close to 0
will show timing impact of the code being tested as it is being
modified.  And this might be useful during development (even though
you might want to measure performance of the module being developed
using other tools).

From cfbolz at gmx.de  Tue Nov 14 23:02:16 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 14 Nov 2006 23:02:16 +0100
Subject: [py-dev] Fwd:  Speed of py.test compared to unittest
In-Reply-To: <5c1d522d0611141336v216cff28s15b9a004cb5276@mail.gmail.com>
References: <Pine.LNX.4.58.0611142133520.20193@martini.genesilico.pl>	<5c1d522d0611141304u42ebd283j5828a720621ec5d6@mail.gmail.com>	<Pine.LNX.4.58.0611142209370.20415@martini.genesilico.pl>	<5c1d522d0611141318t6f224884p80ec1c91c4e8f327@mail.gmail.com>
	<5c1d522d0611141336v216cff28s15b9a004cb5276@mail.gmail.com>
Message-ID: <455A3CE8.5000709@gmx.de>

Pierre Rouleau wrote:
> ---------- Forwarded message ----------
> From: Pierre Rouleau <prouleau001 at gmail.com>
> Date: Nov 14, 2006 4:18 PM
> Subject: Re: [py-dev] Speed of py.test compared to unittest
> To: Maciek Fija??kowski <fijal at genesilico.pl>
>
>
> On 11/14/06, Maciek Fija??kowski <fijal at genesilico.pl> wrote:
>> Sure. Please do.
>>
> Oh, also, as far as startup time is concerned, even though the startup
> time might be constant, a larger startup time will mask differences in
> execution time of the code under test.  Since a unit test system
> should optimally be used during development, a startup time close to 0
> will show timing impact of the code being tested as it is being
> modified.  And this might be useful during development (even though
> you might want to measure performance of the module being developed
> using other tools).

I am not quite sure I buy that argument since py.test tells you the time
that the test itself took (if you use the -v argument) or that all tests
together take (at the end of each test run). As far as I remember, these
times don't include any startup times. Yes, wall clock time of the whole
test run is quite a bad measure, but you don't have to use it anyway.

Cheers,

Carl Friedrich

From prouleau001 at gmail.com  Tue Nov 14 23:07:34 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Tue, 14 Nov 2006 17:07:34 -0500
Subject: [py-dev] Fwd: Speed of py.test compared to unittest
In-Reply-To: <455A3CE8.5000709@gmx.de>
References: <Pine.LNX.4.58.0611142133520.20193@martini.genesilico.pl>
	<5c1d522d0611141304u42ebd283j5828a720621ec5d6@mail.gmail.com>
	<Pine.LNX.4.58.0611142209370.20415@martini.genesilico.pl>
	<5c1d522d0611141318t6f224884p80ec1c91c4e8f327@mail.gmail.com>
	<5c1d522d0611141336v216cff28s15b9a004cb5276@mail.gmail.com>
	<455A3CE8.5000709@gmx.de>
Message-ID: <5c1d522d0611141407gb35968fw56f74140d69db7d@mail.gmail.com>

On 11/14/06, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Pierre Rouleau wrote:
> > ---------- Forwarded message ----------
> > From: Pierre Rouleau <prouleau001 at gmail.com>
> > Date: Nov 14, 2006 4:18 PM
> > Subject: Re: [py-dev] Speed of py.test compared to unittest
> > To: Maciek Fija??kowski <fijal at genesilico.pl>
> >
> >
> > On 11/14/06, Maciek Fija??kowski <fijal at genesilico.pl> wrote:
> >> Sure. Please do.
> >>
> > Oh, also, as far as startup time is concerned, even though the startup
> > time might be constant, a larger startup time will mask differences in
> > execution time of the code under test.  Since a unit test system
> > should optimally be used during development, a startup time close to 0
> > will show timing impact of the code being tested as it is being
> > modified.  And this might be useful during development (even though
> > you might want to measure performance of the module being developed
> > using other tools).
>
> I am not quite sure I buy that argument since py.test tells you the time
> that the test itself took (if you use the -v argument) or that all tests
> together take (at the end of each test run). As far as I remember, these
> times don't include any startup times. Yes, wall clock time of the whole
> test run is quite a bad measure, but you don't have to use it anyway.
>
> Cheers,
>
> Carl Friedrich
>
I didn't realize that the time of *each* test is shown when the -v
option is used.  Thanks for pointing that out.

P.R.

From cfbolz at gmx.de  Tue Nov 14 23:13:38 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 14 Nov 2006 23:13:38 +0100
Subject: [py-dev] Fwd: Speed of py.test compared to unittest
In-Reply-To: <5c1d522d0611141407gb35968fw56f74140d69db7d@mail.gmail.com>
References: <Pine.LNX.4.58.0611142133520.20193@martini.genesilico.pl>	<5c1d522d0611141304u42ebd283j5828a720621ec5d6@mail.gmail.com>	<Pine.LNX.4.58.0611142209370.20415@martini.genesilico.pl>	<5c1d522d0611141318t6f224884p80ec1c91c4e8f327@mail.gmail.com>	<5c1d522d0611141336v216cff28s15b9a004cb5276@mail.gmail.com>	<455A3CE8.5000709@gmx.de>
	<5c1d522d0611141407gb35968fw56f74140d69db7d@mail.gmail.com>
Message-ID: <455A3F92.8060300@gmx.de>

Pierre Rouleau wrote:
> On 11/14/06, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>> I am not quite sure I buy that argument since py.test tells you the time
>> that the test itself took (if you use the -v argument) or that all tests
>> together take (at the end of each test run). As far as I remember, these
>> times don't include any startup times. Yes, wall clock time of the whole
>> test run is quite a bad measure, but you don't have to use it anyway.
>>
>> Cheers,
>>
>> Carl Friedrich
>>
> I didn't realize that the time of *each* test is shown when the -v
> option is used.  Thanks for pointing that out.

you're welcome :-)

Note that I didn't mean to imply that it isn't worthwhile to make
py.test startup time smaller. it's definitely a good thing to do, since
testing should have low overhead.

Cheers,

Carl Friedrich

From fijal at genesilico.pl  Wed Nov 15 12:30:47 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Wed, 15 Nov 2006 12:30:47 +0100
Subject: [py-dev] Fwd: Speed of py.test compared to unittest
In-Reply-To: <455A3F92.8060300@gmx.de>
References: <Pine.LNX.4.58.0611142133520.20193@martini.genesilico.pl>	<5c1d522d0611141304u42ebd283j5828a720621ec5d6@mail.gmail.com>	<Pine.LNX.4.58.0611142209370.20415@martini.genesilico.pl>	<5c1d522d0611141318t6f224884p80ec1c91c4e8f327@mail.gmail.com>	<5c1d522d0611141336v216cff28s15b9a004cb5276@mail.gmail.com>	<455A3CE8.5000709@gmx.de>	<5c1d522d0611141407gb35968fw56f74140d69db7d@mail.gmail.com>
	<455A3F92.8060300@gmx.de>
Message-ID: <455AFA67.60109@genesilico.pl>

Carl Friedrich Bolz wrote:

>Pierre Rouleau wrote:
>  
>
>>On 11/14/06, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>>    
>>
>>>I am not quite sure I buy that argument since py.test tells you the time
>>>that the test itself took (if you use the -v argument) or that all tests
>>>together take (at the end of each test run). As far as I remember, these
>>>times don't include any startup times. Yes, wall clock time of the whole
>>>test run is quite a bad measure, but you don't have to use it anyway.
>>>
>>>Cheers,
>>>
>>>Carl Friedrich
>>>
>>>      
>>>
>>I didn't realize that the time of *each* test is shown when the -v
>>option is used.  Thanks for pointing that out.
>>    
>>
>
>you're welcome :-)
>
>Note that I didn't mean to imply that it isn't worthwhile to make
>py.test startup time smaller. it's definitely a good thing to do, since
>testing should have low overhead.
>
>Cheers,
>
>Carl Friedrich
>_______________________________________________
>py-dev mailing list
>py-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/py-dev
>  
>
I've profiled it a bit. Right now (for me) your tests are about 3x 
slower that unittests. It still can be improved somehow.

Btw: Tests are unfair, cause collection encounters 5k tests for py.test 
and 13 for unittests, if you rewrite it so they'll be equal it would be 
better. It's not good excuse anyway ;-)

I'll try to work a bit more on it, but I guess achieving 2x in this 
particular case would be enough. If you still encounter massive 
slowdowns in different enviroments, do not hesitate to contact us.

Cheers,
Maciej Fijalkowski


From eopadoan at altavix.com  Wed Nov 15 13:06:29 2006
From: eopadoan at altavix.com (Eduardo "EdCrypt" O. Padoan)
Date: Wed, 15 Nov 2006 10:06:29 -0200
Subject: [py-dev] Speed of py.test compared to unittest
In-Reply-To: <5c1d522d0611141152y34d19b92o486e40c03188a904@mail.gmail.com>
References: <5c1d522d0611141152y34d19b92o486e40c03188a904@mail.gmail.com>
Message-ID: <dea92f560611150406t5d6c16fdn20eddb2c7157a36f@mail.gmail.com>

> I ran a test of a simple application that converts roman numeral to
> integer and vice versa (taken from Mike Pilgrim's
> http://diveintopython.org/ ).
> In a test that checks all 4999 possible numbers, unittest performs in
> about 125 mSeconds, while py.test takes about 3.8 seconds.  That's 30
> times slower.
> The unittest and py.test driven scripts perform the same tests.
I've tried to convert the Pilgrim's unittest examples to Py.test too,
and I think the performance using simple asserts inside loops was
acceptable. But using generative tests, I was tremendouly slow.

I you people think attachment is a bad idea, I can think of another
way to share the code I'm talking about.


-- 
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
Blog: http://edcrypt.blogspot.com
Jabber: edcrypt at jabber dot org
ICQ: 161480283
GTalk: eduardo dot padoan at gmail dot com
MSN: eopadoan at altavix dot com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: romantest.py
Type: text/x-python
Size: 4536 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20061115/95613379/attachment.py 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roman_test.py
Type: text/x-python
Size: 7212 bytes
Desc: not available
Url : http://codespeak.net/pipermail/py-dev/attachments/20061115/95613379/attachment-0001.py 

From prouleau001 at gmail.com  Wed Nov 15 17:39:11 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Wed, 15 Nov 2006 11:39:11 -0500
Subject: [py-dev] Fwd:  Fwd: Speed of py.test compared to unittest
In-Reply-To: <5c1d522d0611150837y12fc80d4y5cad8b16a235a4a0@mail.gmail.com>
References: <Pine.LNX.4.58.0611142133520.20193@martini.genesilico.pl>
	<5c1d522d0611141304u42ebd283j5828a720621ec5d6@mail.gmail.com>
	<Pine.LNX.4.58.0611142209370.20415@martini.genesilico.pl>
	<5c1d522d0611141318t6f224884p80ec1c91c4e8f327@mail.gmail.com>
	<5c1d522d0611141336v216cff28s15b9a004cb5276@mail.gmail.com>
	<455A3CE8.5000709@gmx.de>
	<5c1d522d0611141407gb35968fw56f74140d69db7d@mail.gmail.com>
	<455A3F92.8060300@gmx.de> <455AFA67.60109@genesilico.pl>
	<5c1d522d0611150837y12fc80d4y5cad8b16a235a4a0@mail.gmail.com>
Message-ID: <5c1d522d0611150839l4ecf8ff1w64fd5027b26a3470@mail.gmail.com>

On 11/15/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:
> Carl Friedrich Bolz wrote:
>
> >Pierre Rouleau wrote:
> >
> >
> >>On 11/14/06, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> >>
> >>
> >>>I am not quite sure I buy that argument since py.test tells you the time
> >>>that the test itself took (if you use the -v argument) or that all tests
> >>>together take (at the end of each test run). As far as I remember, these
> >>>times don't include any startup times. Yes, wall clock time of the whole
> >>>test run is quite a bad measure, but you don't have to use it anyway.
> >>>
> >>>Cheers,
> >>>
> >>>Carl Friedrich
> >>>
> >>>
> >>>
> >>I didn't realize that the time of *each* test is shown when the -v
> >>option is used.  Thanks for pointing that out.
> >>
> >>
> >
> >you're welcome :-)
> >
> >Note that I didn't mean to imply that it isn't worthwhile to make
> >py.test startup time smaller. it's definitely a good thing to do, since
> >testing should have low overhead.
> >
> >Cheers,
> >
> >Carl Friedrich
> >_______________________________________________
> >py-dev mailing list
> >py-dev at codespeak.net
> >http://codespeak.net/mailman/listinfo/py-dev
> >
> >
> I've profiled it a bit. Right now (for me) your tests are about 3x
> slower that unittests. It still can be improved somehow.
>
> Btw: Tests are unfair, cause collection encounters 5k tests for py.test
> and 13 for unittests, if you rewrite it so they'll be equal it would be
> better. It's not good excuse anyway ;-)
>
> I'll try to work a bit more on it, but I guess achieving 2x in this
> particular case would be enough. If you still encounter massive
> slowdowns in different enviroments, do not hesitate to contact us.
>
True, the code I sent you is not comparing the exact same tests and it
is unfair.
So, as I kept looking into unit test for Python, I found nose and its
nosetests that essentially does the same as py.test (without having
the same design goals as the Py lib).  I ran the same test on both
tools.

The results are:
- py.test tests in [4.30s, 4.17s, 4.28s, 4.42s]
- nosetests tests in [ 1.48s, 1.43s, 1.40s, 1.50s]

So it looks like achieving a 2x would make it run in the same ballpark
as nosetests (at least for that code).

I do like py.test error report better than nosetest though. The
reporting is less verbose.

py.test::

    _______________________________________________________________________________
    ________________________ entrypoint: test_bad_roman[0]
________________________

        def check(exception_cls, invalid_numeral):
            print 'Testing : ', invalid_numeral
    E       raises(exception_cls, roman.fromRoman, invalid_numeral)
    >       ExceptionFailure: DID NOT RAISE

    [D:\dev\python\test\test_roman.py:164]
    - - - - - - - - - - - - - -  [0]: recorded stdout - - - - - - - -
- - - - - - -
    Testing :  MMMM

    _______________________________________________________________________________
    ============ tests finished: 5023 passed, 1 failed in 4.17 seconds
============

and the same failure shown by nosetest::

    ======================================================================
    ERROR: test_roman.test_bad_roman:(<class
roman.InvalidRomanNumeralError at 0x00C5DDB0>, 'MMMM')
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "c:\python24\lib\site-packages\nose-0.9.1-py2.4.egg\nose\case.py",
line 52, in runTest
        self.testFunc()
      File "c:\python24\lib\site-packages\nose-0.9.1-py2.4.egg\nose\loader.py",
line 324, in run
        expr[0](*expr[1:])
      File "D:\dev\python\test\test_roman.py", line 164, in check
        raises(exception_cls, roman.fromRoman, invalid_numeral)
      File "C:\py-dist\py\test\raises.py", line 39, in raises
        expr=args, expected=ExpectedException)
    ExceptionFailure: DID NOT RAISE

    -------------------- >> begin captured stdout << ---------------------
    Testing :  MMMM

    --------------------- >> end captured stdout << ----------------------
    ----------------------------------------------------------------------
    Ran 5024 tests in 1.407s

    FAILED (errors=1)


Cheers,

P.R.

From prouleau001 at gmail.com  Wed Nov 15 18:25:02 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Wed, 15 Nov 2006 12:25:02 -0500
Subject: [py-dev] Fwd: Speed of py.test compared to unittest
In-Reply-To: <455B46E1.1090202@genesilico.pl>
References: <Pine.LNX.4.58.0611142133520.20193@martini.genesilico.pl>
	<Pine.LNX.4.58.0611142209370.20415@martini.genesilico.pl>
	<5c1d522d0611141318t6f224884p80ec1c91c4e8f327@mail.gmail.com>
	<5c1d522d0611141336v216cff28s15b9a004cb5276@mail.gmail.com>
	<455A3CE8.5000709@gmx.de>
	<5c1d522d0611141407gb35968fw56f74140d69db7d@mail.gmail.com>
	<455A3F92.8060300@gmx.de> <455AFA67.60109@genesilico.pl>
	<5c1d522d0611150837y12fc80d4y5cad8b16a235a4a0@mail.gmail.com>
	<455B46E1.1090202@genesilico.pl>
Message-ID: <5c1d522d0611150925o1bfc643alc5091ae67cd4678a@mail.gmail.com>

On 11/15/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:

> >>
> >> I've profiled it a bit. Right now (for me) your tests are about 3x
> >> slower that unittests. It still can be improved somehow.
> >>
> >> Btw: Tests are unfair, cause collection encounters 5k tests for py.test
> >> and 13 for unittests, if you rewrite it so they'll be equal it would be
> >> better. It's not good excuse anyway ;-)
> >>
> >> I'll try to work a bit more on it, but I guess achieving 2x in this
> >> particular case would be enough. If you still encounter massive
> >> slowdowns in different enviroments, do not hesitate to contact us.
> >>
> > True, the code I sent you is not comparing the exact same tests and it
> > is unfair.
> > So, as I kept looking into unit test for Python, I found nose and its
> > nosetests that essentially does the same as py.test (without having
> > the same design goals as the Py lib).  I ran the same test on both
> > tools.
> >
> > The results are:
> > - py.test tests in [4.30s, 4.17s, 4.28s, 4.42s]
> > - nosetests tests in [ 1.48s, 1.43s, 1.40s, 1.50s]
> >
> > So it looks like achieving a 2x would make it run in the same ballpark
> > as nosetests (at least for that code).
> >
> > I do like py.test error report better than nosetest though. The
> > reporting is less verbose.
> >

>
> Btw: it's updated version? (I did some improvements today/yesterday)
>
No!  I re-ran the tests with your latest version and I got faster
results! Great!

The results are now:  [ 1.94s, 1.92s, 1.92s, 1.98s, 1.92s]  which is
much closer to the nosetest results.  Note however, that when I run
nosetests, it executes the *exact* same test, which means that the
test file (test_roman.py) contains:

from py.test import raises

and it uses the raises() call to check that exceptions are raised.  I
am currently looking into nose to see how i could replace the
py.test.raises with nose equivalent.

Cheers,

P.R.

From fijal at genesilico.pl  Wed Nov 15 18:42:21 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Wed, 15 Nov 2006 18:42:21 +0100
Subject: [py-dev] Some fixes to minor typos inside strings
In-Reply-To: <5c1d522d0611150934i739621f3if57a40c683515ce2@mail.gmail.com>
References: <5c1d522d0611150934i739621f3if57a40c683515ce2@mail.gmail.com>
Message-ID: <455B517D.70502@genesilico.pl>

Pierre Rouleau wrote:

> Maciek,
>
> I noticed a couple of typos in the command line strings in
> test/cmdline.py and test/defaultconftest.py.
>
> Here's the diff for the changes I made locally.
>
> The universal diff output files are attached.
>
> Very minor changes, but ...
>
> P.R.
>
>------------------------------------------------------------------------
>
>Index: C:/py-dist/py/test/cmdline.py
>===================================================================
>--- C:/py-dist/py/test/cmdline.py	(revision 34637)
>+++ C:/py-dist/py/test/cmdline.py	(working copy)
>@@ -32,7 +32,7 @@
>         config.option.startserver = True
>     try:
>         if config.getinitialvalue('startserver'):
>-            py.std.warnings.warn("Startserver flag in config is deprecated, use commandline option istead")
>+            py.std.warnings.warn("Startserver flag in config is deprecated, use commandline option instead")
>     except ValueError:
>         pass
>     
>  
>
>------------------------------------------------------------------------
>
>Index: C:/py-dist/py/test/defaultconftest.py
>===================================================================
>--- C:/py-dist/py/test/defaultconftest.py	(revision 34637)
>+++ C:/py-dist/py/test/defaultconftest.py	(working copy)
>@@ -15,7 +15,7 @@
>     py.test.Config.addoptions('general options',
>         Option('-v', '--verbose',
>                action="count", dest="verbose", default=0,
>-               help="increase verbosity"),
>+               help="increase verbosity."),
>         Option('-x', '--exitfirst',
>                action="store_true", dest="exitfirst", default=False,
>                help="exit instantly on first error or failed test."),
>@@ -24,33 +24,33 @@
>                help="disable catching of sys.stdout/stderr output."),
>         Option('-k',
>                action="store", dest="keyword", default='',
>-               help="only run test items matching the given (google-style) keyword expression"),
>+               help="only run test items matching the given (google-style) keyword expression."),
>         Option('-l', '--showlocals',
>                action="store_true", dest="showlocals", default=False,
>-               help="show locals in tracebacks (disabled by default)"),
>+               help="show locals in tracebacks (disabled by default)."),
>         Option('', '--pdb',
>                action="store_true", dest="usepdb", default=False,
>                help="start pdb (the Python debugger) on errors."),
>         Option('', '--tb',
>                action="store", dest="tbstyle", default='long',
>                type="choice", choices=['long', 'short', 'no'],
>-               help="traceback verboseness (long/short/no)"),
>+               help="traceback verboseness (long/short/no)."),
>         Option('', '--fulltrace',
>                action="store_true", dest="fulltrace", default=False,
>-               help="don't cut any tracebacks (default is to cut)"),
>+               help="don't cut any tracebacks (default is to cut)."),
>         Option('', '--nomagic',
>                action="store_true", dest="nomagic", default=False,
>-               help="refrain from using magic as much as possible"),
>+               help="refrain from using magic as much as possible."),
>         Option('', '--collectonly',
>                action="store_true", dest="collectonly", default=False,
>-               help="only collect tests, don't execute them. "),
>+               help="only collect tests, don't execute them."),
>         Option('', '--traceconfig',
>                action="store_true", dest="traceconfig", default=False,
>-               help="trace considerations of conftest.py files. "),
>+               help="trace considerations of conftest.py files."),
>         Option('', '--apigen',
>                action="store_true", dest="apigen", default=False,
>-               help="Generated API docs out of tests. Needs to have defined"\
>-               "__package__ for module or overwritten in conftest")
>+               help="Generated API docs out of tests. Needs to have defined "\
>+               "__package__ for module or overwritten in conftest.")
>     )
>     py.test.Config.addoptions('test-session related options', 
>         Option('', '--tkinter',
>@@ -67,11 +67,11 @@
>                help="python executable to run the tests with. "),
>         Option('-w', '--startserver',
>                action="store_true", dest="startserver", default=False,
>-               help="Start HTTP server listening on localhost:8000 for test"
>+               help="Start HTTP server listening on localhost:8000 for test."
>                ),
>         Option('', '--runbrowser',
>                action="store_true", dest="runbrowser", default=False,
>-               help="Run browser to point to your freshly started web server"
>+               help="Run browser to point to your freshly started web server."
>                ),
>     )
>     
>  
>
Thx a lot. Commited. It really doesn't matter that the changes are 
minor, we appreciate any feedback.

From prouleau001 at gmail.com  Wed Nov 15 22:15:59 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Wed, 15 Nov 2006 16:15:59 -0500
Subject: [py-dev] Another very small typo in test/defaultconftest.py
Message-ID: <5c1d522d0611151315x2538d980q2584205e02d33fe2@mail.gmail.com>

I had made a mistake in my revious post and placed a perdio in a place
where a space character was needed: the help text for --apigen, just
before the '__package__'.

The diff that fixes it is attached.

Cheers,

P.R.
-------------- next part --------------
Index: C:/py-dist/py/test/defaultconftest.py
===================================================================
--- C:/py-dist/py/test/defaultconftest.py	(revision 34641)
+++ C:/py-dist/py/test/defaultconftest.py	(working copy)
@@ -49,7 +49,7 @@
                help="trace considerations of conftest.py files."),
         Option('', '--apigen',
                action="store_true", dest="apigen", default=False,
-               help="Generated API docs out of tests. Needs to have defined"\
+               help="Generated API docs out of tests. Needs to have defined "\
                "__package__ for module or overwritten in conftest.")
     )
     py.test.Config.addoptions('test-session related options', 

From prouleau001 at gmail.com  Thu Nov 16 21:54:47 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Thu, 16 Nov 2006 15:54:47 -0500
Subject: [py-dev] Failing to manage test state of a module with py.test
Message-ID: <5c1d522d0611161254n33f5c0adyf7cbc82029ce4298@mail.gmail.com>

Hi all,

Using the latest of py.test (svn 34683), I can't seem to be able to
control a module test setup using setup_module() as described in
section 2.15 of http://codespeak.net/py/current/doc/test.html

The document gives the following example:

def setup_module(module):
    """ setup up any state specific to the execution
        of the given module.
    """

Now, I am assuming that the the definition of setup_module() must be
written /inside/ the test script that test the module-under-test
tested, right?

Second, I am also assuming that setup_module's argument is the name of
the module-under-test.

Given the above assumptions, if I write a test script to test roman.py
 would be called test_roman.py and would include

def setup_module(roman):
    print 'SETTING up roman for testing....'

And if I ran py.test -s test_roman.py I should be able to see the
printed output. I don't.

So, what do i do wrong here?

Thanks

From fijal at genesilico.pl  Thu Nov 16 22:04:02 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Thu, 16 Nov 2006 22:04:02 +0100
Subject: [py-dev] Failing to manage test state of a module with py.test
In-Reply-To: <5c1d522d0611161254n33f5c0adyf7cbc82029ce4298@mail.gmail.com>
References: <5c1d522d0611161254n33f5c0adyf7cbc82029ce4298@mail.gmail.com>
Message-ID: <455CD242.8080507@genesilico.pl>

Pierre Rouleau wrote:

>Hi all,
>
>Using the latest of py.test (svn 34683), I can't seem to be able to
>control a module test setup using setup_module() as described in
>section 2.15 of http://codespeak.net/py/current/doc/test.html
>
>The document gives the following example:
>
>def setup_module(module):
>    """ setup up any state specific to the execution
>        of the given module.
>    """
>
>Now, I am assuming that the the definition of setup_module() must be
>written /inside/ the test script that test the module-under-test
>tested, right?
>
>Second, I am also assuming that setup_module's argument is the name of
>the module-under-test.
>
>Given the above assumptions, if I write a test script to test roman.py
> would be called test_roman.py and would include
>
>def setup_module(roman):
>    print 'SETTING up roman for testing....'
>
>And if I ran py.test -s test_roman.py I should be able to see the
>printed output. I don't.
>
>So, what do i do wrong here?
>
>Thanks
>_______________________________________________
>py-dev mailing list
>py-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/py-dev
>  
>
Hum. I cannot reproduce you problem (I can clearly see 'SETTING up 
roman...' just after [5024] and before any dots. Yes, this is supposed 
to go to main body of testing module and it receives module object 
itself (not a name)

From prouleau001 at gmail.com  Thu Nov 16 22:22:14 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Thu, 16 Nov 2006 16:22:14 -0500
Subject: [py-dev] Failing to manage test state of a module with py.test
In-Reply-To: <455CD242.8080507@genesilico.pl>
References: <5c1d522d0611161254n33f5c0adyf7cbc82029ce4298@mail.gmail.com>
	<455CD242.8080507@genesilico.pl>
Message-ID: <5c1d522d0611161322t3bfa2ed7od4dc838b14487261@mail.gmail.com>

On 11/16/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:
> Pierre Rouleau wrote:
>
> >Hi all,
> >
> >Using the latest of py.test (svn 34683), I can't seem to be able to
> >control a module test setup using setup_module() as described in
> >section 2.15 of http://codespeak.net/py/current/doc/test.html
> >
> >The document gives the following example:
> >
> >def setup_module(module):
> >    """ setup up any state specific to the execution
> >        of the given module.
> >    """
> >
> >Now, I am assuming that the the definition of setup_module() must be
> >written /inside/ the test script that test the module-under-test
> >tested, right?
> >
> >Second, I am also assuming that setup_module's argument is the name of
> >the module-under-test.
> >
> >Given the above assumptions, if I write a test script to test roman.py
> > would be called test_roman.py and would include
> >
> >def setup_module(roman):
> >    print 'SETTING up roman for testing....'
> >
> >And if I ran py.test -s test_roman.py I should be able to see the
> >printed output. I don't.
> >
> >So, what do i do wrong here?
> >
> >Thanks
> >_______________________________________________
> >py-dev mailing list
> >py-dev at codespeak.net
> >http://codespeak.net/mailman/listinfo/py-dev
> >
> >
> Hum. I cannot reproduce you problem (I can clearly see 'SETTING up
> roman...' just after [5024] and before any dots. Yes, this is supposed
> to go to main body of testing module and it receives module object
> itself (not a name)
>

Sorry, i also got it working if all the setup_module() does is
printing the message.

I forgot to mention that the setup_module() was setting the value of
knownValues after declaring it global.  I though that it would then be
available to all test functions (as is the case with nose), but it's
not.

The setup_module I have looks like this:

def setup_module(roman):
    print 'SETTING UP........................'

    global knownValues
    knownValues = ( (1, 'I'),
                    (2, 'II'),
                    (3, 'III'),
                    (4, 'IV'),
                    (5, 'V'),
                    (6, 'VI'),
                    (7, 'VII'),
                    ....


I wanted to know if the values set up by the setup_module function
would be available to the test functions.  The test function that
fails is failing because knownValues is not accessible to the check
inside test_known_values.

def test_known_values() :
    """Test all known values."""

    def check(number, roman_numeral):
        print 'test_known_values Testing: ', roman_numeral
        assert roman.toRoman(number) == roman_numeral
        assert roman.fromRoman(roman_numeral) == number
        # all Roman numerals should be in upper case
        assert roman_numeral.upper() == roman_numeral
        # lower case Roman numerals are not accepted
        raises(roman.InvalidRomanNumeralError, roman.fromRoman,
roman_numeral.lower())

    tested_numbers = []

    # test the numbers in the table above
    for number, roman_numeral in knownValues:
        yield check, number, roman_numeral
        tested_numbers.append(number)

    # test the others
    for number in xrange(1,5000):
        if number not in tested_numbers:
            yield check, number, roman.toRoman(number)



Note that nose is able to recover the global variable and the test
succeeds in nosetests. py.test does not seem able to do it.  It's not
that I absolutely want to use global variables, but I wanted to checks
the module setup mechanism.

--

P.R.

From fijal at genesilico.pl  Thu Nov 16 22:34:41 2006
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Thu, 16 Nov 2006 22:34:41 +0100
Subject: [py-dev] Failing to manage test state of a module with py.test
In-Reply-To: <5c1d522d0611161322t3bfa2ed7od4dc838b14487261@mail.gmail.com>
References: <5c1d522d0611161254n33f5c0adyf7cbc82029ce4298@mail.gmail.com>	
	<455CD242.8080507@genesilico.pl>
	<5c1d522d0611161322t3bfa2ed7od4dc838b14487261@mail.gmail.com>
Message-ID: <455CD971.5010402@genesilico.pl>

Pierre Rouleau wrote:

> On 11/16/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:
>
>> Pierre Rouleau wrote:
>>
>> >Hi all,
>> >
>> >Using the latest of py.test (svn 34683), I can't seem to be able to
>> >control a module test setup using setup_module() as described in
>> >section 2.15 of http://codespeak.net/py/current/doc/test.html
>> >
>> >The document gives the following example:
>> >
>> >def setup_module(module):
>> >    """ setup up any state specific to the execution
>> >        of the given module.
>> >    """
>> >
>> >Now, I am assuming that the the definition of setup_module() must be
>> >written /inside/ the test script that test the module-under-test
>> >tested, right?
>> >
>> >Second, I am also assuming that setup_module's argument is the name of
>> >the module-under-test.
>> >
>> >Given the above assumptions, if I write a test script to test roman.py
>> > would be called test_roman.py and would include
>> >
>> >def setup_module(roman):
>> >    print 'SETTING up roman for testing....'
>> >
>> >And if I ran py.test -s test_roman.py I should be able to see the
>> >printed output. I don't.
>> >
>> >So, what do i do wrong here?
>> >
>> >Thanks
>> >_______________________________________________
>> >py-dev mailing list
>> >py-dev at codespeak.net
>> >http://codespeak.net/mailman/listinfo/py-dev
>> >
>> >
>> Hum. I cannot reproduce you problem (I can clearly see 'SETTING up
>> roman...' just after [5024] and before any dots. Yes, this is supposed
>> to go to main body of testing module and it receives module object
>> itself (not a name)
>>
>
> Sorry, i also got it working if all the setup_module() does is
> printing the message.
>
> I forgot to mention that the setup_module() was setting the value of
> knownValues after declaring it global.  I though that it would then be
> available to all test functions (as is the case with nose), but it's
> not.
>
> The setup_module I have looks like this:
>
> def setup_module(roman):
>    print 'SETTING UP........................'
>
>    global knownValues
>    knownValues = ( (1, 'I'),
>                    (2, 'II'),
>                    (3, 'III'),
>                    (4, 'IV'),
>                    (5, 'V'),
>                    (6, 'VI'),
>                    (7, 'VII'),
>                    ....
>
>
> I wanted to know if the values set up by the setup_module function
> would be available to the test functions.  The test function that
> fails is failing because knownValues is not accessible to the check
> inside test_known_values.
>
> def test_known_values() :
>    """Test all known values."""
>
>    def check(number, roman_numeral):
>        print 'test_known_values Testing: ', roman_numeral
>        assert roman.toRoman(number) == roman_numeral
>        assert roman.fromRoman(roman_numeral) == number
>        # all Roman numerals should be in upper case
>        assert roman_numeral.upper() == roman_numeral
>        # lower case Roman numerals are not accepted
>        raises(roman.InvalidRomanNumeralError, roman.fromRoman,
> roman_numeral.lower())
>
>    tested_numbers = []
>
>    # test the numbers in the table above
>    for number, roman_numeral in knownValues:
>        yield check, number, roman_numeral
>        tested_numbers.append(number)
>
>    # test the others
>    for number in xrange(1,5000):
>        if number not in tested_numbers:
>            yield check, number, roman.toRoman(number)
>
>
>
> Note that nose is able to recover the global variable and the test
> succeeds in nosetests. py.test does not seem able to do it.  It's not
> that I absolutely want to use global variables, but I wanted to checks
> the module setup mechanism.
>
> -- 
>
> P.R.

Of course tha you just write:

def setup_module(mod):
    mod.some_global_value = whatever_you_like

:-) It's of course better, because explicit is better than implicit (you 
avoid exporting all variables used in setup_)

From prouleau001 at gmail.com  Thu Nov 16 22:43:30 2006
From: prouleau001 at gmail.com (Pierre Rouleau)
Date: Thu, 16 Nov 2006 16:43:30 -0500
Subject: [py-dev] Failing to manage test state of a module with py.test
In-Reply-To: <455CD971.5010402@genesilico.pl>
References: <5c1d522d0611161254n33f5c0adyf7cbc82029ce4298@mail.gmail.com>
	<455CD242.8080507@genesilico.pl>
	<5c1d522d0611161322t3bfa2ed7od4dc838b14487261@mail.gmail.com>
	<455CD971.5010402@genesilico.pl>
Message-ID: <5c1d522d0611161343p317b142dl5a76d9d8aaffd97e@mail.gmail.com>

On 11/16/06, Maciek Fijalkowski <fijal at genesilico.pl> wrote:
> Pierre Rouleau wrote:
>

> >
> > I forgot to mention that the setup_module() was setting the value of
> > knownValues after declaring it global.  I though that it would then be
> > available to all test functions (as is the case with nose), but it's
> > not.
> >
> > The setup_module I have looks like this:
> >
> > def setup_module(roman):
> >    print 'SETTING UP........................'
> >
> >    global knownValues
> >    knownValues = ( (1, 'I'),
> >                    (2, 'II'),

> > Note that nose is able to recover the global variable and the test
> > succeeds in nosetests. py.test does not seem able to do it.  It's not
> > that I absolutely want to use global variables, but I wanted to checks
> > the module setup mechanism.
> >
>
> Of course tha you just write:
>
> def setup_module(mod):
>     mod.some_global_value = whatever_you_like
>
> :-) It's of course better, because explicit is better than implicit (you
> avoid exporting all variables used in setup_)
>

But of course!!! what was I thinking! ;)  Now I see why there is a
module argument!!

Thanks!

From hpk at trillke.net  Fri Nov 17 08:17:46 2006
From: hpk at trillke.net (holger krekel)
Date: Fri, 17 Nov 2006 08:17:46 +0100
Subject: [py-dev] Failing to manage test state of a module with py.test
In-Reply-To: <455CD971.5010402@genesilico.pl>
References: <5c1d522d0611161254n33f5c0adyf7cbc82029ce4298@mail.gmail.com>
	<455CD242.8080507@genesilico.pl>
	<5c1d522d0611161322t3bfa2ed7od4dc838b14487261@mail.gmail.com>
	<455CD971.5010402@genesilico.pl>
Message-ID: <20061117071746.GG32728@solar.trillke.net>

On Thu, Nov 16, 2006 at 22:34 +0100, Maciek Fijalkowski wrote:
> Pierre Rouleau wrote:
> > def setup_module(roman):
> >    print 'SETTING UP........................'
> >
> >    global knownValues
> >    knownValues = ( (1, 'I'),
> >                    (2, 'II'),
> >                    (3, 'III'),
> >                    (4, 'IV'),
> >                    (5, 'V'),
> >                    (6, 'VI'),
> >                    (7, 'VII'),
> >                    ....
> >
> >
> > I wanted to know if the values set up by the setup_module function
> > would be available to the test functions.  [...]
> >
> Of course tha you just write:
> 
> def setup_module(mod):
>     mod.some_global_value = whatever_you_like
> 
> :-) It's of course better, because explicit is better than implicit (you 
> avoid exporting all variables used in setup_)

yes, that is the usual way, but i am not sure why Pierre's code 
fails, there is no obvious reason, unless the setup_module 
is actually imported from somewhere else in which case
the "test_roman" module source and the setup_module 
would not share the same "globals" - this is the reason 
why it is better to use the argument, because you can then 
share "setup_module" code across various test modules. 

best, 

    holger