From holger at merlinux.eu  Fri Jan  1 19:37:36 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 1 Jan 2010 19:37:36 +0100
Subject: [py-dev] funcarg in a class
In-Reply-To: <e1ac8ece0912310925h5cad4807m7095d00c3da0f9fa@mail.gmail.com>
References: <e1ac8ece0912310925h5cad4807m7095d00c3da0f9fa@mail.gmail.com>
Message-ID: <20100101183736.GU3516@trillke.net>

On Thu, Dec 31, 2009 at 17:25 +0000, Joan Miller wrote:
> Is possible to run a funcarg inner of a class? The nex code doesnt works.
> 
> --------------------------
> class TestFoo(object):
> 
>     def pytest_funcarg__myfuncarg(self, request):
>         return 13
> 
> 
>     def test_function(self, append):
>         assert self.myfuncarg == 13

you need to pass in "myfuncarg" instead of "append". 
That should work fine. 

cheers,
holger


From holger at merlinux.eu  Fri Jan  1 19:46:25 2010
From: holger at merlinux.eu (holger krekel)
Date: Fri, 1 Jan 2010 19:46:25 +0100
Subject: [py-dev] funcarg in a class
In-Reply-To: <20100101183736.GU3516@trillke.net>
References: <e1ac8ece0912310925h5cad4807m7095d00c3da0f9fa@mail.gmail.com>
	<20100101183736.GU3516@trillke.net>
Message-ID: <20100101184625.GV3516@trillke.net>

On Fri, Jan 01, 2010 at 19:37 +0100, holger krekel wrote:
> On Thu, Dec 31, 2009 at 17:25 +0000, Joan Miller wrote:
> > Is possible to run a funcarg inner of a class? The nex code doesnt works.
> > 
> > --------------------------
> > class TestFoo(object):
> > 
> >     def pytest_funcarg__myfuncarg(self, request):
> >         return 13
> > 
> > 
> >     def test_function(self, append):
> >         assert self.myfuncarg == 13
> 
> you need to pass in "myfuncarg" instead of "append". 
> That should work fine. 

to be precise:

    def test_function(self, myfuncarg):
        assert myfuncarg == 13

should work.  or do you mean something else? 

cheers and happy new year! 
holger


From peloko45 at gmail.com  Fri Jan  1 23:58:11 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Fri, 1 Jan 2010 22:58:11 +0000
Subject: [py-dev] funcarg in a class
In-Reply-To: <20100101184625.GV3516@trillke.net>
References: <e1ac8ece0912310925h5cad4807m7095d00c3da0f9fa@mail.gmail.com>
	<20100101183736.GU3516@trillke.net>
	<20100101184625.GV3516@trillke.net>
Message-ID: <e1ac8ece1001011458h2b803c0cod9abdf205aee2d5e@mail.gmail.com>

Thanks! I could solve it after of having written to the mailing list.
Sometimes the things go out when you make something in the background.

Happy new year!

2010/1/1 holger krekel <holger at merlinux.eu>:
> On Fri, Jan 01, 2010 at 19:37 +0100, holger krekel wrote:
>> On Thu, Dec 31, 2009 at 17:25 +0000, Joan Miller wrote:
>> > Is possible to run a funcarg inner of a class? The nex code doesnt works.
>> >
>> > --------------------------
>> > class TestFoo(object):
>> >
>> > ? ? def pytest_funcarg__myfuncarg(self, request):
>> > ? ? ? ? return 13
>> >
>> >
>> > ? ? def test_function(self, append):
>> > ? ? ? ? assert self.myfuncarg == 13
>>
>> you need to pass in "myfuncarg" instead of "append".
>> That should work fine.
>
> to be precise:
>
> ? ?def test_function(self, myfuncarg):
> ? ? ? ?assert myfuncarg == 13
>
> should work. ?or do you mean something else?
>
> cheers and happy new year!
> holger
>


From holger at merlinux.eu  Sat Jan  2 17:42:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 2 Jan 2010 17:42:54 +0100
Subject: [py-dev] happy new year / testing resources
Message-ID: <20100102164254.GX3516@trillke.net>

Hi all, 

i hope you all had a good entry into 2010, happy new decade! :)

The last days i have been on and off working towards a 1.2 
release.  One of the new bits is direct xml/junit reporting.
In fact i have been playing with Hudson as a build integration 
server, am quite happy so far. In case you'd like to see 
here is some preliminiary access: http://mer1.ath.cx:8080 
will put it somewhere more public soon. 

One thing i'd like to have is some more Boxes to play with :)
So if you can provide some virtual environment even only during
certain times, please contact me.  Personally, I use VirtualBox 
(after having used lots of XEN and a bit of KVM) and am quite 
happy with it, very easy to get going.  Connecting to the hudson 
master can be done in a "PULL" fashion and due to the virtualization 
is rather safe.  

cheers,
holger


From pedronis at openend.se  Sun Jan  3 15:14:11 2010
From: pedronis at openend.se (Samuele Pedroni)
Date: Sun, 03 Jan 2010 15:14:11 +0100
Subject: [py-dev] ANN: oejskit 0.8.7 JavaScript in-browser testing with
 py.test plugin and unittest.py glue
Message-ID: <4B40A633.9040000@openend.se>

Hi, I just pushed a new release of OE jskit 0.8.7 to PyPI. Main points
of interest:

- user-defined naming of browsers for the remote browser script so that
it is easier to run a test suite for example against machines running
ie7 and ie8 both, see "Remote browsers" in the doc for more details.

- the glue code to run JavaScript tests with unittest.py is now documented

- compatibility with py.test 1.1.1 cleanups, the plugin is now exposed
to py.test through a setuptools entry point

About OE jskit:

jskit contains infrastructure and in particular a py.test plugin to
enable running unit tests for JavaScript code inside browsers.
It contains also glue code to run JavaScript tests from unittest.py
based test suites.

The approach also enables to write integration tests such that the
JavaScript code is tested against server-side Python code mocked as
necessary. Any server-side framework that can already be exposed through
WSGI can play.

The plugin requires py.test 1.1.1 and should also work with current trunk.

More information and downloading at:

http://pypi.python.org/pypi/oejskit

including a changelog, documentation and the talk I gave at Europython 2009.

jskit was initially developed by Open End AB and is released under the
MIT license.

In various incarnations it has been in use and useful at Open End for
more than two years, we are quite happy to share it.

Samuele Pedroni for Open End

















From peloko45 at gmail.com  Sat Jan  9 11:15:02 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Sat, 9 Jan 2010 10:15:02 +0000
Subject: [py-dev] Ignore some tests
Message-ID: <e1ac8ece1001090215n70d1ef30sb8ea5de168eb7bf7@mail.gmail.com>

How to ignore any tests? Now I'm commenting the tests that I wann't
that they been runned but this is not optimal.


From Adam.Schmalhofer at gmx.de  Sat Jan  9 11:33:39 2010
From: Adam.Schmalhofer at gmx.de (Adam)
Date: Sat, 9 Jan 2010 11:33:39 +0100
Subject: [py-dev] Ignore some tests
In-Reply-To: <e1ac8ece1001090215n70d1ef30sb8ea5de168eb7bf7@mail.gmail.com>
References: <e1ac8ece1001090215n70d1ef30sb8ea5de168eb7bf7@mail.gmail.com>
Message-ID: <20100109113339.4d8c9ddf@deepthought>

Joan Miller wrote:

> Now I'm commenting the tests that I wann't
> that they been runned but this is not optimal.

http://codespeak.net/py/dist/test/features.html#advanced-test-selection-and-running-modes

http://codespeak.net/py/dist/test/plugin/skipping.html

--Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20100109/e5ba4e33/attachment.pgp>

From Ronny.Pfannschmidt at gmx.de  Sat Jan 16 11:08:34 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sat, 16 Jan 2010 11:08:34 +0100
Subject: [py-dev] output collect failure i dont quiete get
Message-ID: <1263636514.7949.150.camel@localhost>

hi,

while investigating some failing tests for pidas vim integration i
discovered that somehow some output is missing

for comparisation

/////////////////////////////////////////////////////////////////////////////////////////////
$ py.test
pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
inserting into sys.path: /home/ronny/Projects/py
============================= test session starts
==============================
python: platform linux2 -- Python 2.6.4 -- pytest-1.2.0a1
test object 1:
pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor

pida/editors/vim/test_pidavim.py E

==================================== ERRORS
====================================
_____________ ERROR at setup of TestVim.test_append_text_at_cursor
_____________

self = <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>
method = <bound method TestVim.test_append_text_at_cursor of
<pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>>

    def setup_method(self, method=None):
        self.vim_process = _start_vim()
        time.sleep(1)
>       self.vim = get_vim('pidatest')

pida/editors/vim/test_pidavim.py:51: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ 

uid = 'pidatest'

    def get_vim(uid):
        session = dbus.SessionBus()
        for _try in range(10):
            try:
                log.debug('trying vim connect #%s', _try)
                return session.get_object(get_bus_name(uid), '/vim')
            except dbus.DBusException:
                log.debug('vim connect failed, retrying')
                time.sleep(0.1)
>       raise RuntimeError('Vim Connect Failed')
E       RuntimeError: Vim Connect Failed

pida/editors/vim/client.py:39: RuntimeError
------------------------------- Captured stdout
--------------------------------
Vim: Caught deadly signal SEGV

Vim: Finished.

/////////////////////////////////////////////////////////////////////////////////////////////
$ nosetests
pida.editors.vim.test_pidavim:TestVim.test_append_text_at_cursor
beginning vim startup
modules loaded
get uuid
make service
made service
setup gui
done setup gui
Vim: Caught deadly signal SEGV
Vim: Finished.
E
======================================================================
ERROR: pida.editors.vim.test_pidavim.TestVim.test_append_text_at_cursor
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/nose/case.py", line 364, in
setUp
    try_run(self.inst, ('setup', 'setUp'))
  File "/usr/lib64/python2.6/site-packages/nose/util.py", line 487, in
try_run
    return func()
  File
"/home/ronny/Projects/pida/main/pida/editors/vim/test_pidavim.py", line
51, in setup_method
    self.vim = get_vim('pidatest')
  File "/home/ronny/Projects/pida/main/pida/editors/vim/client.py", line
39, in get_vim
    raise RuntimeError('Vim Connect Failed')
RuntimeError: Vim Connect Failed

----------------------------------------------------------------------
Ran 1 test in 2.051s

FAILED (errors=1)
/////////////////////////////////////////////////////////////////////////////////////////////

i suppose this relates to py.test's output captureing and vim's
behaviour wrt not having a pty

any idea how to work around that without just disableing the captureing?

Regards Ronny



From holger at merlinux.eu  Sat Jan 16 11:56:17 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Jan 2010 11:56:17 +0100
Subject: [py-dev] output collect failure i dont quiete get
In-Reply-To: <1263636514.7949.150.camel@localhost>
References: <1263636514.7949.150.camel@localhost>
Message-ID: <20100116105617.GE3516@trillke.net>

Moin Ronny,

sorry, i can not reproduce the issue - probably i am missing something. 
Could you come up with a minimal example and tell how you 
invoke nosetests and py.test?  Maybe also use some paste service 
so that they are more nicely readable.  And are you using the released
or trunk-nosetests? 

cheers,
holger

On Sat, Jan 16, 2010 at 11:08 +0100, Ronny Pfannschmidt wrote:
> hi,
> 
> while investigating some failing tests for pidas vim integration i
> discovered that somehow some output is missing
> 
> for comparisation
> 
> /////////////////////////////////////////////////////////////////////////////////////////////
> $ py.test
> pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> inserting into sys.path: /home/ronny/Projects/py
> ============================= test session starts
> ==============================
> python: platform linux2 -- Python 2.6.4 -- pytest-1.2.0a1
> test object 1:
> pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> 
> pida/editors/vim/test_pidavim.py E
> 
> ==================================== ERRORS
> ====================================
> _____________ ERROR at setup of TestVim.test_append_text_at_cursor
> _____________
> 
> self = <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>
> method = <bound method TestVim.test_append_text_at_cursor of
> <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>>
> 
>     def setup_method(self, method=None):
>         self.vim_process = _start_vim()
>         time.sleep(1)
> >       self.vim = get_vim('pidatest')
> 
> pida/editors/vim/test_pidavim.py:51: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ 
> 
> uid = 'pidatest'
> 
>     def get_vim(uid):
>         session = dbus.SessionBus()
>         for _try in range(10):
>             try:
>                 log.debug('trying vim connect #%s', _try)
>                 return session.get_object(get_bus_name(uid), '/vim')
>             except dbus.DBusException:
>                 log.debug('vim connect failed, retrying')
>                 time.sleep(0.1)
> >       raise RuntimeError('Vim Connect Failed')
> E       RuntimeError: Vim Connect Failed
> 
> pida/editors/vim/client.py:39: RuntimeError
> ------------------------------- Captured stdout
> --------------------------------
> Vim: Caught deadly signal SEGV
> 
> Vim: Finished.
> 
> /////////////////////////////////////////////////////////////////////////////////////////////
> $ nosetests
> pida.editors.vim.test_pidavim:TestVim.test_append_text_at_cursor
> beginning vim startup
> modules loaded
> get uuid
> make service
> made service
> setup gui
> done setup gui
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> E
> ======================================================================
> ERROR: pida.editors.vim.test_pidavim.TestVim.test_append_text_at_cursor
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib64/python2.6/site-packages/nose/case.py", line 364, in
> setUp
>     try_run(self.inst, ('setup', 'setUp'))
>   File "/usr/lib64/python2.6/site-packages/nose/util.py", line 487, in
> try_run
>     return func()
>   File
> "/home/ronny/Projects/pida/main/pida/editors/vim/test_pidavim.py", line
> 51, in setup_method
>     self.vim = get_vim('pidatest')
>   File "/home/ronny/Projects/pida/main/pida/editors/vim/client.py", line
> 39, in get_vim
>     raise RuntimeError('Vim Connect Failed')
> RuntimeError: Vim Connect Failed
> 
> ----------------------------------------------------------------------
> Ran 1 test in 2.051s
> 
> FAILED (errors=1)
> /////////////////////////////////////////////////////////////////////////////////////////////
> 
> i suppose this relates to py.test's output captureing and vim's
> behaviour wrt not having a pty
> 
> any idea how to work around that without just disableing the captureing?
> 
> Regards Ronnyk
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 


From Ronny.Pfannschmidt at gmx.de  Sat Jan 16 11:59:04 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sat, 16 Jan 2010 11:59:04 +0100
Subject: [py-dev] output collect failure i dont quiete get
In-Reply-To: <20100116105617.GE3516@trillke.net>
References: <1263636514.7949.150.camel@localhost>
	<20100116105617.GE3516@trillke.net>
Message-ID: <1263639544.7949.153.camel@localhost>

On Sat, 2010-01-16 at 11:56 +0100, holger krekel wrote:
> Moin Ronny,
> 
> sorry, i can not reproduce the issue - probably i am missing something. 
> Could you come up with a minimal example and tell how you 
> invoke nosetests and py.test?  Maybe also use some paste service 
> so that they are more nicely readable.  And are you using the released
> or trunk-nosetests? 
the issue is vim changing output behaviour based on having a pty on
stdin
> 
> cheers,
> holger
> 
> On Sat, Jan 16, 2010 at 11:08 +0100, Ronny Pfannschmidt wrote:
> > hi,
> > 
> > while investigating some failing tests for pidas vim integration i
> > discovered that somehow some output is missing
> > 
> > for comparisation
> > 
> > /////////////////////////////////////////////////////////////////////////////////////////////
> > $ py.test
> > pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> > inserting into sys.path: /home/ronny/Projects/py
> > ============================= test session starts
> > ==============================
> > python: platform linux2 -- Python 2.6.4 -- pytest-1.2.0a1
> > test object 1:
> > pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> > 
> > pida/editors/vim/test_pidavim.py E
> > 
> > ==================================== ERRORS
> > ====================================
> > _____________ ERROR at setup of TestVim.test_append_text_at_cursor
> > _____________
> > 
> > self = <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>
> > method = <bound method TestVim.test_append_text_at_cursor of
> > <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>>
> > 
> >     def setup_method(self, method=None):
> >         self.vim_process = _start_vim()
> >         time.sleep(1)
> > >       self.vim = get_vim('pidatest')
> > 
> > pida/editors/vim/test_pidavim.py:51: 
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> > _ _ _ _ 
> > 
> > uid = 'pidatest'
> > 
> >     def get_vim(uid):
> >         session = dbus.SessionBus()
> >         for _try in range(10):
> >             try:
> >                 log.debug('trying vim connect #%s', _try)
> >                 return session.get_object(get_bus_name(uid), '/vim')
> >             except dbus.DBusException:
> >                 log.debug('vim connect failed, retrying')
> >                 time.sleep(0.1)
> > >       raise RuntimeError('Vim Connect Failed')
> > E       RuntimeError: Vim Connect Failed
> > 
> > pida/editors/vim/client.py:39: RuntimeError
> > ------------------------------- Captured stdout
> > --------------------------------
> > Vim: Caught deadly signal SEGV
> > 
> > Vim: Finished.
> > 
> > /////////////////////////////////////////////////////////////////////////////////////////////
> > $ nosetests
> > pida.editors.vim.test_pidavim:TestVim.test_append_text_at_cursor
> > beginning vim startup
> > modules loaded
> > get uuid
> > make service
> > made service
> > setup gui
> > done setup gui
> > Vim: Caught deadly signal SEGV
> > Vim: Finished.
> > E
> > ======================================================================
> > ERROR: pida.editors.vim.test_pidavim.TestVim.test_append_text_at_cursor
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >   File "/usr/lib64/python2.6/site-packages/nose/case.py", line 364, in
> > setUp
> >     try_run(self.inst, ('setup', 'setUp'))
> >   File "/usr/lib64/python2.6/site-packages/nose/util.py", line 487, in
> > try_run
> >     return func()
> >   File
> > "/home/ronny/Projects/pida/main/pida/editors/vim/test_pidavim.py", line
> > 51, in setup_method
> >     self.vim = get_vim('pidatest')
> >   File "/home/ronny/Projects/pida/main/pida/editors/vim/client.py", line
> > 39, in get_vim
> >     raise RuntimeError('Vim Connect Failed')
> > RuntimeError: Vim Connect Failed
> > 
> > ----------------------------------------------------------------------
> > Ran 1 test in 2.051s
> > 
> > FAILED (errors=1)
> > /////////////////////////////////////////////////////////////////////////////////////////////
> > 
> > i suppose this relates to py.test's output captureing and vim's
> > behaviour wrt not having a pty
> > 
> > any idea how to work around that without just disableing the captureing?
> > 
> > Regards Ronnyk
> > 
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> > 
> 



From holger at merlinux.eu  Sat Jan 16 12:16:37 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 16 Jan 2010 12:16:37 +0100
Subject: [py-dev] output collect failure i dont quiete get
In-Reply-To: <1263639544.7949.153.camel@localhost>
References: <1263636514.7949.150.camel@localhost>
	<20100116105617.GE3516@trillke.net>
	<1263639544.7949.153.camel@localhost>
Message-ID: <20100116111637.GF3516@trillke.net>

On Sat, Jan 16, 2010 at 11:59 +0100, Ronny Pfannschmidt wrote:
> On Sat, 2010-01-16 at 11:56 +0100, holger krekel wrote:
> > Moin Ronny,
> > 
> > sorry, i can not reproduce the issue - probably i am missing something. 
> > Could you come up with a minimal example and tell how you 
> > invoke nosetests and py.test?  Maybe also use some paste service 
> > so that they are more nicely readable.  And are you using the released
> > or trunk-nosetests? 
> the issue is vim changing output behaviour based on having a pty on
> stdin

So if i understand it correctly: py.test indeed by default
opens /dev/null and puts that file to sys.stdin (also on fd-level)
so that tests can not hang waiting for input.  I guess
we could introduce an option to leave stdin alone. Alternatively
you could maybe use os.openpty and dup that to filedescriptor 0
before invoking vim-machinery?

cheers,
holger

P.S.: I spent 20+ minutes on this previously - i'd appreciate if you tried
to be a bit more precise than "somehow some output is missing" and a bunch of
tracebacks.  

> > 
> > cheers,
> > holger
> > 
> > On Sat, Jan 16, 2010 at 11:08 +0100, Ronny Pfannschmidt wrote:
> > > hi,
> > > 
> > > while investigating some failing tests for pidas vim integration i
> > > discovered that somehow some output is missing
> > > 
> > > for comparisation
> > > 
> > > /////////////////////////////////////////////////////////////////////////////////////////////
> > > $ py.test
> > > pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> > > inserting into sys.path: /home/ronny/Projects/py
> > > ============================= test session starts
> > > ==============================
> > > python: platform linux2 -- Python 2.6.4 -- pytest-1.2.0a1
> > > test object 1:
> > > pida::editors::vim::test_pidavim.py::TestVim::test_append_text_at_cursor
> > > 
> > > pida/editors/vim/test_pidavim.py E
> > > 
> > > ==================================== ERRORS
> > > ====================================
> > > _____________ ERROR at setup of TestVim.test_append_text_at_cursor
> > > _____________
> > > 
> > > self = <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>
> > > method = <bound method TestVim.test_append_text_at_cursor of
> > > <pida.editors.vim.test_pidavim.TestVim object at 0x1874b50>>
> > > 
> > >     def setup_method(self, method=None):
> > >         self.vim_process = _start_vim()
> > >         time.sleep(1)
> > > >       self.vim = get_vim('pidatest')
> > > 
> > > pida/editors/vim/test_pidavim.py:51: 
> > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> > > _ _ _ _ 
> > > 
> > > uid = 'pidatest'
> > > 
> > >     def get_vim(uid):
> > >         session = dbus.SessionBus()
> > >         for _try in range(10):
> > >             try:
> > >                 log.debug('trying vim connect #%s', _try)
> > >                 return session.get_object(get_bus_name(uid), '/vim')
> > >             except dbus.DBusException:
> > >                 log.debug('vim connect failed, retrying')
> > >                 time.sleep(0.1)
> > > >       raise RuntimeError('Vim Connect Failed')
> > > E       RuntimeError: Vim Connect Failed
> > > 
> > > pida/editors/vim/client.py:39: RuntimeError
> > > ------------------------------- Captured stdout
> > > --------------------------------
> > > Vim: Caught deadly signal SEGV
> > > 
> > > Vim: Finished.
> > > 
> > > /////////////////////////////////////////////////////////////////////////////////////////////
> > > $ nosetests
> > > pida.editors.vim.test_pidavim:TestVim.test_append_text_at_cursor
> > > beginning vim startup
> > > modules loaded
> > > get uuid
> > > make service
> > > made service
> > > setup gui
> > > done setup gui
> > > Vim: Caught deadly signal SEGV
> > > Vim: Finished.
> > > E
> > > ======================================================================
> > > ERROR: pida.editors.vim.test_pidavim.TestVim.test_append_text_at_cursor
> > > ----------------------------------------------------------------------
> > > Traceback (most recent call last):
> > >   File "/usr/lib64/python2.6/site-packages/nose/case.py", line 364, in
> > > setUp
> > >     try_run(self.inst, ('setup', 'setUp'))
> > >   File "/usr/lib64/python2.6/site-packages/nose/util.py", line 487, in
> > > try_run
> > >     return func()
> > >   File
> > > "/home/ronny/Projects/pida/main/pida/editors/vim/test_pidavim.py", line
> > > 51, in setup_method
> > >     self.vim = get_vim('pidatest')
> > >   File "/home/ronny/Projects/pida/main/pida/editors/vim/client.py", line
> > > 39, in get_vim
> > >     raise RuntimeError('Vim Connect Failed')
> > > RuntimeError: Vim Connect Failed
> > > 
> > > ----------------------------------------------------------------------
> > > Ran 1 test in 2.051s
> > > 
> > > FAILED (errors=1)
> > > /////////////////////////////////////////////////////////////////////////////////////////////
> > > 
> > > i suppose this relates to py.test's output captureing and vim's
> > > behaviour wrt not having a pty
> > > 
> > > any idea how to work around that without just disableing the captureing?
> > > 
> > > Regards Ronnyk
> > > 
> > > _______________________________________________
> > > py-dev mailing list
> > > py-dev at codespeak.net
> > > http://codespeak.net/mailman/listinfo/py-dev
> > > 
> > 
> 

-- 


From Ronny.Pfannschmidt at gmx.de  Sun Jan 17 18:53:47 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 17 Jan 2010 18:53:47 +0100
Subject: [py-dev] how to configure additional traceback cut-out
Message-ID: <1263750827.29378.3.camel@localhost>

hi,

while debugging vim-dbus use, 
i'd like to remove all those nasty line-nosie alike traceback iems  from
the python dbus libs as they don't really help the traceback.

Is there any way to do that right now or does it need invention.

-- Ronny



From holger at merlinux.eu  Sun Jan 17 20:25:18 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 17 Jan 2010 20:25:18 +0100
Subject: [py-dev] how to configure additional traceback cut-out
In-Reply-To: <1263750827.29378.3.camel@localhost>
References: <1263750827.29378.3.camel@localhost>
Message-ID: <20100117192517.GD30119@trillke.net>

Hi Ronny, 

On Sun, Jan 17, 2010 at 18:53 +0100, Ronny Pfannschmidt wrote:
> hi,
> 
> while debugging vim-dbus use, 
> i'd like to remove all those nasty line-nosie alike traceback iems  from
> the python dbus libs as they don't really help the traceback.
> 
> Is there any way to do that right now or does it need invention.

No way yet.  The "__tracebackhide__ = True" setting only works for code
you control, obviously.  

However, the internal ExceptionInfo() object has support for processing
tracebacks so i guess we could add a hook that you can use like this:

    # ./conftest.py
    def pytest_filter_traceback(excinfo):
        dbuspath = py.path.local(dbus.__file__).dirpath()
        excinfo.traceback = excinfo.traceback.filter(
            lambda entry: not entry.path.relto(dbuspath))

This hook should not be called when "--tb=full" is specified, i guess.

makes sense to you? 

cheers,
holger


From Ronny.Pfannschmidt at gmx.de  Sun Jan 17 20:49:25 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 17 Jan 2010 20:49:25 +0100
Subject: [py-dev] how to configure additional traceback cut-out
In-Reply-To: <20100117192517.GD30119@trillke.net>
References: <1263750827.29378.3.camel@localhost>
	<20100117192517.GD30119@trillke.net>
Message-ID: <1263757765.29378.26.camel@localhost>

On Sun, 2010-01-17 at 20:25 +0100, holger krekel wrote:
> Hi Ronny, 
> 
> On Sun, Jan 17, 2010 at 18:53 +0100, Ronny Pfannschmidt wrote:
> > hi,
> > 
> > while debugging vim-dbus use, 
> > i'd like to remove all those nasty line-nosie alike traceback iems  from
> > the python dbus libs as they don't really help the traceback.
> > 
> > Is there any way to do that right now or does it need invention.
> 
> No way yet.  The "__tracebackhide__ = True" setting only works for code
> you control, obviously.  
> 
> However, the internal ExceptionInfo() object has support for processing
> tracebacks so i guess we could add a hook that you can use like this:
> 
>     # ./conftest.py
>     def pytest_filter_traceback(excinfo):
>         dbuspath = py.path.local(dbus.__file__).dirpath()
>         excinfo.traceback = excinfo.traceback.filter(
>             lambda entry: not entry.path.relto(dbuspath))
> 
> This hook should not be called when "--tb=full" is specified, i guess.
> 
> makes sense to you? 
> 
that looks very sensible, i'll take a look at where to put that, 
seems like traceback pruning is somewhere in collect

since its about filtering tracebacks,
how about having it take a traceback and return one
so one could do something like:

def pytest_filter_traceback(traceback):
   dbuspath = py.path.local(dbus.__file__).dirpath()
   return traceback.filter(lambda entry: not entry.path.relto(dbuspath))


-- Ronny



From holger at merlinux.eu  Sun Jan 17 21:16:03 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 17 Jan 2010 21:16:03 +0100
Subject: [py-dev] how to configure additional traceback cut-out
In-Reply-To: <1263757765.29378.26.camel@localhost>
References: <1263750827.29378.3.camel@localhost>
	<20100117192517.GD30119@trillke.net>
	<1263757765.29378.26.camel@localhost>
Message-ID: <20100117201603.GE30119@trillke.net>

On Sun, Jan 17, 2010 at 20:49 +0100, Ronny Pfannschmidt wrote:
> On Sun, 2010-01-17 at 20:25 +0100, holger krekel wrote:
> > Hi Ronny, 
> > 
> > On Sun, Jan 17, 2010 at 18:53 +0100, Ronny Pfannschmidt wrote:
> > > hi,
> > > 
> > > while debugging vim-dbus use, 
> > > i'd like to remove all those nasty line-nosie alike traceback iems  from
> > > the python dbus libs as they don't really help the traceback.
> > > 
> > > Is there any way to do that right now or does it need invention.
> > 
> > No way yet.  The "__tracebackhide__ = True" setting only works for code
> > you control, obviously.  
> > 
> > However, the internal ExceptionInfo() object has support for processing
> > tracebacks so i guess we could add a hook that you can use like this:
> > 
> >     # ./conftest.py
> >     def pytest_filter_traceback(excinfo):
> >         dbuspath = py.path.local(dbus.__file__).dirpath()
> >         excinfo.traceback = excinfo.traceback.filter(
> >             lambda entry: not entry.path.relto(dbuspath))
> > 
> > This hook should not be called when "--tb=full" is specified, i guess.
> > 
> > makes sense to you? 
> > 
> that looks very sensible, i'll take a look at where to put that, 
> seems like traceback pruning is somewhere in collect
> 
> since its about filtering tracebacks,
> how about having it take a traceback and return one
> so one could do something like:
> 
> def pytest_filter_traceback(traceback):
>    dbuspath = py.path.local(dbus.__file__).dirpath()
>    return traceback.filter(lambda entry: not entry.path.relto(dbuspath))

This would inhibit having multiple hooks involved. There is no
hook-call mode which allows to "chain", so far it wasn't 
strictly needed. 

Adding pytest_filter_traceback to py/_plugin/hookspec.py 
and shifting the traceback.filter() call in pycollect.py::_prunetraceback 
to a default hook in py/_plugin/pytest_default.py and adding
a self.ihook.pytest_filter_traceback(excinfo=excinfo) instead should 
be enough to allow a custom conftest.py hook.  And of course a test in 
testing/test_pycollect.py::TestConftestCustomization

cheers,
holger


From Ronny.Pfannschmidt at gmx.de  Sun Jan 17 22:27:54 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Sun, 17 Jan 2010 22:27:54 +0100
Subject: [py-dev] confusion on traceback.cut
Message-ID: <1263763674.29378.36.camel@localhost>

Hi,
just played around with traceback cut/filter
but i don't understand whats happening here:

        >>> import py
        >>> py._pydir
        local('/home/ronny/Projects/py/py')
        >>> e = py.test.raises(ValueError, "int('a')")
        >>> tb = e.traceback
        >>> tb.cut(excludepath=py._pydir)
        [<TracebackEntry /home/ronny/Projects/py/py/_test/outcome.py:89>, <TracebackEntry /home/ronny/Projects/py/py/_builtin.py:179>, <TracebackEntry <string>:5>, <TracebackEntry <codegen /home/ronny/Projects/py/py/_test/outcome.py:88>:1>]


i expected it to remove the first few items

on the other hand
        >>> tb.filter(lambda x:not
        py.path.local(x.path).relto(py._pydir))
        [<TracebackEntry <string>:5>, <TracebackEntry
        <codegen /home/ronny/Projects/py/py/_test/outcome.py:88>:1>]
        
seems to do exactly that and i expected it to filter the last entry, too

can we please clarify what each of those really.

ps:
        ~/Projects/py $ hg id
        201d526c373c (trunk) tip

Regards Ronny




From holger at merlinux.eu  Mon Jan 18 03:06:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 03:06:54 +0100
Subject: [py-dev] confusion on traceback.cut
In-Reply-To: <1263763674.29378.36.camel@localhost>
References: <1263763674.29378.36.camel@localhost>
Message-ID: <20100118020654.GF30119@trillke.net>

Hi Ronny,

On Sun, Jan 17, 2010 at 22:27 +0100, Ronny Pfannschmidt wrote:
> Hi,
> just played around with traceback cut/filter
> but i don't understand whats happening here:
> 
>         >>> import py
>         >>> py._pydir
>         local('/home/ronny/Projects/py/py')
>         >>> e = py.test.raises(ValueError, "int('a')")
>         >>> tb = e.traceback
>         >>> tb.cut(excludepath=py._pydir)
>         [<TracebackEntry /home/ronny/Projects/py/py/_test/outcome.py:89>, <TracebackEntry /home/ronny/Projects/py/py/_builtin.py:179>, <TracebackEntry <string>:5>, <TracebackEntry <codegen /home/ronny/Projects/py/py/_test/outcome.py:88>:1>]

A slightly special case because other than the pydir only
synthetic code is involved (generated source).  If you have 
at least one "real" entry not relative to pydir it should work. 
Anyway, i changed this in rev1610 - let's see if it causes 
any problems (in py.test reporting).

> i expected it to remove the first few items
> 
> on the other hand
>         >>> tb.filter(lambda x:not
>         py.path.local(x.path).relto(py._pydir))
>         [<TracebackEntry <string>:5>, <TracebackEntry
>         <codegen /home/ronny/Projects/py/py/_test/outcome.py:88>:1>]
>         
> seems to do exactly that and i expected it to filter the last entry, too

The last entry is generated source, what you see if where it got generated.
By passing in a filter function you override the default filter
lambda x: not x.ishidden().  You can "AND" that in your lambda. 

> can we please clarify what each of those really.

hope it is now.

holger


From Ronny.Pfannschmidt at gmx.de  Mon Jan 18 12:00:48 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 18 Jan 2010 12:00:48 +0100
Subject: [py-dev] how should i handle errors in the traceback filter hooks
Message-ID: <1263812448.25759.8.camel@localhost>

hi,

i just finished the initial version of the traceback filter hook
while it was just as simple as holger said, i lack an idea on how to
handle errors in that hook.

btw, the current patch is http://paste.pocoo.org/show/166660/


so it spills out a nasty/huge internalerror if i make misstakes in my
own implementations of that hook within a conftest.

tests will be written once i figure the error handling

-- Ronny



From holger at merlinux.eu  Mon Jan 18 14:58:25 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 14:58:25 +0100
Subject: [py-dev] how should i handle errors in the traceback
	filter	hooks
In-Reply-To: <1263812448.25759.8.camel@localhost>
References: <1263812448.25759.8.camel@localhost>
Message-ID: <20100118135825.GK30119@trillke.net>

On Mon, Jan 18, 2010 at 12:00 +0100, Ronny Pfannschmidt wrote:
> hi,
> 
> i just finished the initial version of the traceback filter hook
> while it was just as simple as holger said, i lack an idea on how to
> handle errors in that hook.
> 
> btw, the current patch is http://paste.pocoo.org/show/166660/
> 
> 
> so it spills out a nasty/huge internalerror if i make misstakes in my
> own implementations of that hook within a conftest.

for now, i'd catch the exception and just use the un-abbreviated traceback. 

Maybe you can issue a hook.pytest_trace("filter_traceback", msg)
which one could see if "--debug" or "--traceconfig" is given. 

holger

> tests will be written once i figure the error handling
> 
> -- Ronny
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 


From fijall at gmail.com  Mon Jan 18 15:50:56 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 18 Jan 2010 15:50:56 +0100
Subject: [py-dev] Is codespeak issue tracker still active?
Message-ID: <693bc9ab1001180650p51b27400s6d0014ade90fc659@mail.gmail.com>

I mean this guy:

https://codespeak.net/issue/py-dev/index

If it's not, probably a redirect would be good.
If it's working, then something went wrong with styles, at least for me.

Cheers,
fijal


From holger at merlinux.eu  Mon Jan 18 15:55:58 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 15:55:58 +0100
Subject: [py-dev] Is codespeak issue tracker still active?
In-Reply-To: <693bc9ab1001180650p51b27400s6d0014ade90fc659@mail.gmail.com>
References: <693bc9ab1001180650p51b27400s6d0014ade90fc659@mail.gmail.com>
Message-ID: <20100118145558.GL30119@trillke.net>

Hi Maciej,

On Mon, Jan 18, 2010 at 15:50 +0100, Maciej Fijalkowski wrote:
> I mean this guy:
> 
> https://codespeak.net/issue/py-dev/index
> 
> If it's not, probably a redirect would be good.
> If it's working, then something went wrong with styles, at least for me.

i disabled it now - as described in http://pylib.org/contact.html please use 

    http://bitbucket.org/hpk42/py-trunk/issues

or the mailing list here.

cheers,
holger


From Ronny.Pfannschmidt at gmx.de  Mon Jan 18 16:14:04 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Mon, 18 Jan 2010 16:14:04 +0100
Subject: [py-dev] another traceback cut weirdness
Message-ID: <1263827644.25759.13.camel@localhost>

i just noticed that traceback.cut will return a traceback
with all other filtering undone again
since it passes a raw traceback entry into the Traceback ctor.

is there any deeper reason for that or did it just work, cause cutting
always was first

if its not intentional i could add a .filter(lambda entry: entry in
self) to get it solved

-- Ronny



From holger at merlinux.eu  Mon Jan 18 16:24:36 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 16:24:36 +0100
Subject: [py-dev] another traceback cut weirdness
In-Reply-To: <1263827644.25759.13.camel@localhost>
References: <1263827644.25759.13.camel@localhost>
Message-ID: <20100118152436.GM30119@trillke.net>

Hi Ronny,

On Mon, Jan 18, 2010 at 16:14 +0100, Ronny Pfannschmidt wrote:
> i just noticed that traceback.cut will return a traceback
> with all other filtering undone again
> since it passes a raw traceback entry into the Traceback ctor.
> 
> is there any deeper reason for that or did it just work, cause cutting
> always was first

probably. The whole machinery was done for py.test which obviously
invokes it in a certain way. 

> if its not intentional i could add a .filter(lambda entry: entry in
> self) to get it solved

Sounds ok although i am not sure it's that easy.  Let's maybe 
continue any more discussion off-list as i guess not too many 
people here are interested in the details ... 

cheers,
holger


From holger at merlinux.eu  Mon Jan 18 17:34:33 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 18 Jan 2010 17:34:33 +0100
Subject: [py-dev] py.test-1.2.0: junitxml, standalone test scripts,
	pluginization
Message-ID: <20100118163433.GO30119@trillke.net>

Hi all, 

i just released some bits related to testing: 

  py-1.2.0: py.test core which grew junitxml, standalone-script generation 
  pytest-xdist-1.0: separately installable dist-testing & looponfailing plugin
  pytest-figleaf-1.0: separately installable figleaf-coverage testing plugin

See below or at this URL for the announcement:

    http://pylib.org/announce/release-1.2.0.html

If you didn't experience much speed-up or had previously problems with 
distributed testing i recommend you try to install "pytest-xdist" now and see 
if it works better. For me it speeds up some tests runs by 500% on a 4 CPU
machine due to its better internal model and several fixes.  (It's five
times because several tests depend on IO and don't block CPU meanwhile).

Another tip: if you use "pip" (best with a virtualenv) you can do e.g.:

    pip install pytest-xdist 
    pip uninstall pytest-xdist 

to conveniently activate/deactivate plugins for py.test. easy_install 
works ok as well but has no uninstall, yet remains the only option 
for installing with Python3 at the moment, though.  You need to use
the 'distribute' project's easy_install for that. 

cheers & have fun,
holger


py.test/pylib 1.2.0: junitxml, standalone test scripts, pluginization
--------------------------------------------------------------------------------

py.test is an advanced automated testing tool working with
Python2, Python3 and Jython versions on all major operating
systems.  It has a simple plugin architecture and can run many 
existing common Python test suites without modification.  It offers 
some unique features not found in other testing tools.  
See http://pytest.org for more info.

py.test 1.2.0 brings many bug fixes and interesting new abilities:

* --junitxml=path will create an XML file for use with CI processing 
* --genscript=path creates a standalone py.test-equivalent test-script 
* --ignore=path prevents collection of anything below that path
* --confcutdir=path only lookup conftest.py test configs below that path
* a 'pytest_report_header' hook to add info to the terminal report header 
* a 'pytestconfig' function argument gives direct access to option values
* 'pytest_generate_tests' can now be put into a class as well 
* on CPython py.test additionally installs as "py.test-VERSION", on
  Jython as py.test-jython and on PyPy as py.test-pypy-XYZ

Apart from many bug fixes 1.2.0 also has better pluginization: 
Distributed testing and looponfailing testing now live in the
separately installable 'pytest-xdist' plugin.  The same is true for
'pytest-figleaf' for doing coverage reporting.  Those two plugins
can serve well now as blue prints for doing your own.  

thanks to all who helped and gave feedback,
have fun,

holger krekel, January 2010

Changes between 1.2.0 and 1.1.1
=====================================

- moved dist/looponfailing from py.test core into a new 
  separately released pytest-xdist plugin.

- new junitxml plugin: --junitxml=path will generate a junit style xml file
  which is processable e.g. by the Hudson CI system. 

- new option: --genscript=path will generate a standalone py.test script
  which will not need any libraries installed.  thanks to Ralf Schmitt. 

- new option: --ignore will prevent specified path from collection. 
  Can be specified multiple times. 

- new option: --confcutdir=dir will make py.test only consider conftest 
  files that are relative to the specified dir.  

- new funcarg: "pytestconfig" is the pytest config object for access
  to command line args and can now be easily used in a test. 

- install 'py.test' and `py.which` with a ``-$VERSION`` suffix to
  disambiguate between Python3, python2.X, Jython and PyPy installed versions. 

- new "pytestconfig" funcarg allows access to test config object

- new "pytest_report_header" hook can return additional lines 
  to be displayed at the header of a test run. 

- (experimental) allow "py.test path::name1::name2::..." for pointing
  to a test within a test collection directly.  This might eventually
  evolve as a full substitute to "-k" specifications. 

- streamlined plugin loading: order is now as documented in
  customize.html: setuptools, ENV, commandline, conftest. 
  also setuptools entry point names are turned to canonical namees ("pytest_*")

- automatically skip tests that need 'capfd' but have no os.dup 

- allow pytest_generate_tests to be defined in classes as well 

- deprecate usage of 'disabled' attribute in favour of pytestmark 
- deprecate definition of Directory, Module, Class and Function nodes
  in conftest.py files.  Use pytest collect hooks instead.

- collection/item node specific runtest/collect hooks are only called exactly
  on matching conftest.py files, i.e. ones which are exactly below
  the filesystem path of an item

- change: the first pytest_collect_directory hook to return something
  will now prevent further hooks to be called.

- change: figleaf plugin now requires --figleaf to run.  Also
  change its long command line options to be a bit shorter (see py.test -h).

- change: pytest doctest plugin is now enabled by default and has a
  new option --doctest-glob to set a pattern for file matches. 

- change: remove internal py._* helper vars, only keep py._pydir 

- robustify capturing to survive if custom pytest_runtest_setup 
  code failed and prevented the capturing setup code from running. 

- make py.test.* helpers provided by default plugins visible early -
  works transparently both for pydoc and for interactive sessions
  which will regularly see e.g. py.test.mark and py.test.importorskip. 

- simplify internal plugin manager machinery 
- simplify internal collection tree by introducing a RootCollector node

- fix assert reinterpreation that sees a call containing "keyword=..."

- fix issue66: invoke pytest_sessionstart and pytest_sessionfinish 
  hooks on slaves during dist-testing, report module/session teardown 
  hooks correctly.

- fix issue65: properly handle dist-testing if no 
  execnet/py lib installed remotely. 

- skip some install-tests if no execnet is available

- fix docs, fix internal bin/ script generation

-- 


From holger at merlinux.eu  Tue Jan 19 16:18:37 2010
From: holger at merlinux.eu (holger krekel)
Date: Tue, 19 Jan 2010 16:18:37 +0100
Subject: [py-dev] py.test-1.2.0: junitxml, standalone test scripts,
	pluginization
In-Reply-To: <20100118163433.GO30119@trillke.net>
References: <20100118163433.GO30119@trillke.net>
Message-ID: <20100119151837.GR30119@trillke.net>

On Mon, Jan 18, 2010 at 17:34 +0100, holger krekel wrote:
>   pytest-xdist-1.0: separately installable dist-testing & looponfailing plugin

pytest-xdist-1.1 is out, which avoids an indefinite hang if you have
few and quick hosts, and some fast-to-run tests.  The test-master would
in some cases end up wanting to avoid a busy-loop but in fact 
would stall because the test nodes were also waiting for new tasks. 
"pip install -U pytest-xdist" should fix this race condition now. 

holger


From wmark at hurrikane.de  Wed Jan 20 18:28:58 2010
From: wmark at hurrikane.de (W-Mark Kubacki)
Date: Wed, 20 Jan 2010 18:28:58 +0100
Subject: [py-dev] [patch] greenlet on ARM/linux
In-Reply-To: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com>
References: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com>
Message-ID: <9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com>

Hi,

last year Renaud Blanch has provided a patch for ARM/Apple. [1]
Based on his works I have ported 'greenlet' to ARM (EABI, non-thumb;
all tests passed). Please find my patch attached.

-- 
Gr??e, Mark
http://mark.ossdl.de/
(I am no subscriber to this list; regdarding this topic please CC me.)

[1] http://codespeak.net/pipermail/py-dev/2009q1/001066.html


From wmark at hurrikane.de  Wed Jan 20 18:32:54 2010
From: wmark at hurrikane.de (W-Mark Kubacki)
Date: Wed, 20 Jan 2010 18:32:54 +0100
Subject: [py-dev] [patch] greenlet on ARM/linux
In-Reply-To: <9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com>
References: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com>
	<9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com>
Message-ID: <9bca96021001200932y633eb2b5tf468b898ba03255f@mail.gmail.com>

2010/1/20 W-Mark Kubacki <wmark at hurrikane.de>:
> Please find my patch attached.

Here comes the attachment. Sorry.

-- 
Gr??e, Mark
http://mark.ossdl.de/
(I am no subscriber to this list; regdarding this topic please CC me.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: greenlet-0.2-arm.patch
Type: application/octet-stream
Size: 2423 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20100120/1062410b/attachment.obj>

From holger at merlinux.eu  Wed Jan 20 21:20:03 2010
From: holger at merlinux.eu (holger krekel)
Date: Wed, 20 Jan 2010 21:20:03 +0100
Subject: [py-dev] [patch] greenlet on ARM/linux
In-Reply-To: <9bca96021001200932y633eb2b5tf468b898ba03255f@mail.gmail.com>
References: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com>
	<9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com>
	<9bca96021001200932y633eb2b5tf468b898ba03255f@mail.gmail.com>
Message-ID: <20100120202003.GB30119@trillke.net>

On Wed, Jan 20, 2010 at 18:32 +0100, W-Mark Kubacki wrote:
> 2010/1/20 W-Mark Kubacki <wmark at hurrikane.de>:
> > Please find my patch attached.
> 
> Here comes the attachment. Sorry.

Very cool but i am afraid greenlet is not distributed with the 
py lib for a longer time now. So you need to contact other people - 
there was Bob Ippolito and others who did releases.  If you 
want to grab it and release a new "greenlet" yourself that 
could work and many people would be happy i guess, myself included. 

cheers,
holger


From holger at merlinux.eu  Sat Jan 23 00:43:01 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 23 Jan 2010 00:43:01 +0100
Subject: [py-dev] always call teardownX even if setupX fails?
Message-ID: <20100122234301.GX30119@trillke.net>

Hi all, (cross-post, beware)

i'd appreciate some feedback regarding a decision related to this issue: 
http://bitbucket.org/hpk42/py-trunk/issue/78/
where Jeff Stearns suggests to call teardown_module in any case. 

To summarize here, please consider this:

    def setup_module(mod):
        ...

    def teardown_module(mod):
        ...

Currently teardown_module will not be called if setup_module raises
an error.  This is consistent with how nosetests and unittest.py behave
(although unitttest doesn't yet have setup_module/class, but it has
setUp/tearDown).

For py.test we could easily change it such that teardown_module is called 
independently if the call to setup_module succeeded.  The same would be 
true for setup_class/teardown_class and setup_method/teardown_method pairs.  
The rationale behind this is that setup_XYZ may set up several resources
and fail somewhere in between.  Not calling teardown_XYZ leaves 
resources unfinalized, potentially causing test setup failures in other test
modules (this is what happend to Jeff). 

Do you think it would actually hurt to call teardown in any case? 
That might cause another error of course - with py.test you would both: 

    http://paste.pocoo.org/show/168612

Doesn't look like a blocker to me at the moment.  What do you think? 
Any objections or recommendations?  Do you regard consistency a blocker? 

Note that the whole issue is not a problem with funcargs and recent unittest: 
you usually set up exactly one funcarg in a factory and if that fails 
there usually is no reason to call teardown.  And if a function gets 
several funcargs, each successful funcarg setup will have a guaranteed call
to the finalizer even if different funcarg factory calls fail.  Moreover, 
you can always use "addfinalizer()" in a factory (similar to the recent unittest 
addition addCleanup()) which will trigger an unconditionally teardown. 

cheers,
(feel free to leave out one of the cross-posted mailing lists),
holger

-- 


From peloko45 at gmail.com  Sat Jan 23 14:45:13 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Sat, 23 Jan 2010 13:45:13 +0000
Subject: [py-dev] Local import
In-Reply-To: <20091223144216.GD3516@trillke.net>
References: <e1ac8ece0912230528s57821f4bs283bff026d0e3340@mail.gmail.com>
	<20091223144216.GD3516@trillke.net>
Message-ID: <e1ac8ece1001230545g5860624bt79657d97df718ce0@mail.gmail.com>

I was wrong since that it isn't necessary to import the source from
tests. It's better to use 'python setup.py develop' because it manages
well this problem.

"When you're installing a distribution, you can install it in develop
mode instead with python setup.py develop. Using this mode, a special
link file is created in your site-packages directory. This link points
back to the current folder or 'root package'. Any changes you make to
the software here will be reflected immediately without having to do
an install again.

When you're ready to install for good do a real install."

http://www.siafoo.net/article/77#install-vs-develop


2009/12/23 holger krekel <holger at merlinux.eu>:
> On Wed, Dec 23, 2009 at 13:28 +0000, Joan Miller wrote:
>> I'm using the next function to access to the source from tests without
>> install it (python setup.py develop). It's very usefull during
>> development so it could be added to py.
>
> If you use 'python setup.py develop' you should be able to
> import your package that you are currently working on already.
>
> Can you post an example how and from which file you use
> the posted function?
>
> cheers,
> holger
>
>
>> ------------------------
>> import os
>> import sys
>>
>> def import_local(parent='test', child='lib'):
>> ? ? """Inserts local library on 'sys.path'.
>>
>> ? ? Goes up until the root of the project (upper of 'parent' directory)
>> ? ? and inserts the 'child' directory.
>> ? ? """
>> ? ? parent_path = os.path.abspath(os.path.dirname(__file__))
>>
>> ? ? while parent in os.path.basename(parent_path):
>> ? ? ? ? parent_path = os.path.dirname(parent_path)
>>
>> ? ? sys.path.insert(0, os.path.join(parent_path, child))
>> ------------------------
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>
>
> --
>


From holger at merlinux.eu  Wed Jan 27 18:05:49 2010
From: holger at merlinux.eu (holger krekel)
Date: Wed, 27 Jan 2010 18:05:49 +0100
Subject: [py-dev] 1.2.1 planned next week
Message-ID: <20100127170549.GT6083@trillke.net>

Hi all, 

if you have anything small regarding py.test that you'd like to see addressed
please speak up. I plan to release a 1.2.1 end next week.

cheers,
holger


From holger at merlinux.eu  Wed Jan 27 18:07:45 2010
From: holger at merlinux.eu (holger krekel)
Date: Wed, 27 Jan 2010 18:07:45 +0100
Subject: [py-dev] [TIP] always call teardownX even if setupX fails?
In-Reply-To: <C801E576-C394-4BCA-A5B5-6F0FF71B3941@gmail.com>
References: <20100122234301.GX30119@trillke.net>
	<1264243919.5710.1.camel@lifeless-64>
	<C801E576-C394-4BCA-A5B5-6F0FF71B3941@gmail.com>
Message-ID: <20100127170745.GU6083@trillke.net>

Hi Rob, hi Doug,

On Sat, Jan 23, 2010 at 10:47 -0500, Doug Hellmann wrote:
>
> On Jan 23, 2010, at 5:51 AM, Robert Collins wrote:
>
>> On Sat, 2010-01-23 at 00:43 +0100, holger krekel wrote:
>>>
>>> Doesn't look like a blocker to me at the moment.  What do you think?
>>> Any objections or recommendations?  Do you regard consistency a
>>> blocker?
>>
>> Trial and testtools run tearDown unconditionally even though its
>> inconsistent with unittest. I'm a big fan of doing that, and encourage
>> you to do it in py.test.
>
> +1
>
> Any test with moderately complex external fixtures would benefit from  
> this behavior.  We use a subclass of unittest.TestCase that always calls 
> tearDown() for all of our tests at Racemi.

thanks for your feedback.  py.test will do that as well with 1.2.1 - with 
the addition that triggering "Skipped" exceptions in a setup function will 
not call teardown.

cheers,
holger


From peloko45 at gmail.com  Wed Jan 27 23:44:36 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Wed, 27 Jan 2010 22:44:36 +0000
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100127170549.GT6083@trillke.net>
References: <20100127170549.GT6083@trillke.net>
Message-ID: <e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>

py.cleanup is very usefull, but it also would be usefull to delete the
next directories (in bash would be):

  $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info

2010/1/27 holger krekel <holger at merlinux.eu>:
> Hi all,
>
> if you have anything small regarding py.test that you'd like to see addressed
> please speak up. I plan to release a 1.2.1 end next week.
>
> cheers,
> holger
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
>


From holger at merlinux.eu  Thu Jan 28 13:10:18 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jan 2010 13:10:18 +0100
Subject: [py-dev] [TIP] always call teardownX even if setupX fails?
In-Reply-To: <1264627143.6394.24.camel@lifeless-64>
References: <20100122234301.GX30119@trillke.net>
	<1264243919.5710.1.camel@lifeless-64>
	<C801E576-C394-4BCA-A5B5-6F0FF71B3941@gmail.com>
	<20100127170745.GU6083@trillke.net>
	<1264627143.6394.24.camel@lifeless-64>
Message-ID: <20100128121018.GY6083@trillke.net>

On Thu, Jan 28, 2010 at 08:19 +1100, Robert Collins wrote:
> On Wed, 2010-01-27 at 18:07 +0100, holger krekel wrote:
> > 
> > > Any test with moderately complex external fixtures would benefit
> > from  
> > > this behavior.  We use a subclass of unittest.TestCase that always
> > calls 
> > > tearDown() for all of our tests at Racemi.
> > 
> > thanks for your feedback.  py.test will do that as well with 1.2.1 -
> > with 
> > the addition that triggering "Skipped" exceptions in a setup function
> > will 
> > not call teardown.
> 
> Why not?
> 
> Consider:
> 
> setUp:
>    self.foo = get_foo()
>    if not isinstance(self.foo, TestableThing):
>        raise TestSkipped()
> 
> Why should this /not/ call tearDown ?

not calling teardown seemed slightly easier to implement ... i can work
a bit harder though :) 

However, I haven't see your example pattern with py.test usages yet.  
Is this a an example from actual code? 

And if so do you have have and use it in setup_module and setup_class - alike 
methods? 

cheers,
holger


From holger at merlinux.eu  Thu Jan 28 13:54:54 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jan 2010 13:54:54 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
Message-ID: <20100128125454.GC6083@trillke.net>

On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
> py.cleanup is very usefull, but it also would be usefull to delete the
> next directories (in bash would be):
> 
>   $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info

i see how this can make sense.  Any idea how/if this should
be made configurable?  In my case *.egg-info as a general
to-be-removed pattern would make sense, i guess. 

Hum, would "py.cleanup -a" (aka cleanup including all 
typically setup.py-generated files) make sense? 
I also guess that removing "$py.class" for 
jython-generated classfiles also makes sense. 

cheers,
holger


 
> 2010/1/27 holger krekel <holger at merlinux.eu>:
> > Hi all,
> >
> > if you have anything small regarding py.test that you'd like to see addressed
> > please speak up. I plan to release a 1.2.1 end next week.
> >
> > cheers,
> > holger
> > _______________________________________________
> > py-dev mailing list
> > py-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/py-dev
> >
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 

-- 


From holger at merlinux.eu  Thu Jan 28 14:31:16 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 28 Jan 2010 14:31:16 +0100
Subject: [py-dev] [TIP] always call teardownX even if setupX fails?
In-Reply-To: <1264682821.24790.8.camel@lifeless-64>
References: <20100122234301.GX30119@trillke.net>
	<1264243919.5710.1.camel@lifeless-64>
	<C801E576-C394-4BCA-A5B5-6F0FF71B3941@gmail.com>
	<20100127170745.GU6083@trillke.net>
	<1264627143.6394.24.camel@lifeless-64>
	<20100128121018.GY6083@trillke.net>
	<1264682821.24790.8.camel@lifeless-64>
Message-ID: <20100128133116.GE6083@trillke.net>

On Thu, Jan 28, 2010 at 23:47 +1100, Robert Collins wrote:
> On Thu, 2010-01-28 at 13:10 +0100, holger krekel wrote:
> > 
> > 
> > not calling teardown seemed slightly easier to implement ... i can
> > work
> > a bit harder though :) 
> > 
> > However, I haven't see your example pattern with py.test usages yet.  
> > Is this a an example from actual code? 
> 
> Broadly yes. Usually seen more like this in fact:
> 
> class A
>    setUp(): does stuff
> 
> class B(A):
>    setUp(): check if we should skip

If you can you'd probably first try to see if to skip and then 
call the base class' setUp(), though.  Anyway, ... 
 
> > And if so do you have have and use it in setup_module and setup_class
> > - alike 
> > methods?
> 
> I don't use such methods, so no (see prior conversation about decoupling
> resources etc).

... these cases were what seemed complicated to me. 
However, it turned out, my previous implementation was buggy anyway! 
So now there is no special casing for Skip anymore and teardown gets called
in all cases - and i also refined the "setup_module/class" calling to  
only happen exactly once (before they'd be happen multiple times for each
test if they raised an error).  Also added two functional and one unit-test
and hope things are settled now :) 

many thanks for your feedback and insistance on clarity here! 

cheers,
holger


From peloko45 at gmail.com  Thu Jan 28 19:11:40 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Thu, 28 Jan 2010 18:11:40 +0000
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100128125454.GC6083@trillke.net>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
	<20100128125454.GC6083@trillke.net>
Message-ID: <e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>

2010/1/28 holger krekel <holger at merlinux.eu>:
> On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
>> py.cleanup is very usefull, but it also would be usefull to delete the
>> next directories (in bash would be):
>>
>> ? $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info
>
> i see how this can make sense. ?Any idea how/if this should
> be made configurable? ?In my case *.egg-info as a general
> to-be-removed pattern would make sense, i guess.
I agree into a general pattern to delete the eggs info.

> Hum, would "py.cleanup -a" (aka cleanup including all
> typically setup.py-generated files) make sense?
> I also guess that removing "$py.class" for
> jython-generated classfiles also makes sense.
It's ok, at least for me


From Ronny.Pfannschmidt at gmx.de  Thu Jan 28 23:24:03 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Thu, 28 Jan 2010 23:24:03 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
	<20100128125454.GC6083@trillke.net>
	<e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>
Message-ID: <1264717443.8246.0.camel@localhost>

On Thu, 2010-01-28 at 18:11 +0000, Joan Miller wrote:
> 2010/1/28 holger krekel <holger at merlinux.eu>:
> > On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
> >> py.cleanup is very usefull, but it also would be usefull to delete the
> >> next directories (in bash would be):
> >>
> >>   $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info
> >
> > i see how this can make sense.  Any idea how/if this should
> > be made configurable?  In my case *.egg-info as a general
> > to-be-removed pattern would make sense, i guess.
> I agree into a general pattern to delete the eggs info.
its actually more tricky, as setup.py develop needs them
> 
> > Hum, would "py.cleanup -a" (aka cleanup including all
> > typically setup.py-generated files) make sense?
> > I also guess that removing "$py.class" for
> > jython-generated classfiles also makes sense.
> It's ok, at least for me
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev



From Adam.Schmalhofer at gmx.de  Fri Jan 29 00:00:13 2010
From: Adam.Schmalhofer at gmx.de (Adam)
Date: Fri, 29 Jan 2010 00:00:13 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <1264717443.8246.0.camel@localhost>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
	<20100128125454.GC6083@trillke.net>
	<e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>
	<1264717443.8246.0.camel@localhost>
Message-ID: <20100129000013.1d80031f@deepthought>

Ronny Pfannschmidt wrote:

> On Thu, 2010-01-28 at 18:11 +0000, Joan Miller wrote:
> > 2010/1/28 holger krekel <holger at merlinux.eu>:
> > > On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
> > >> py.cleanup is very usefull, but it also would be usefull to delete the
> > >> next directories (in bash would be):
> > >>
> > >>   $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info
> > >
> > > i see how this can make sense.  Any idea how/if this should
> > > be made configurable?  In my case *.egg-info as a general
> > > to-be-removed pattern would make sense, i guess.
> > I agree into a general pattern to delete the eggs info.
> its actually more tricky, as setup.py develop needs them

I think it is harmless, as distribute is going to delete the directory
on setup.py clean:

http://bitbucket.org/tarek/distribute/issue/122/setuppy-clean-should-delete-sourcestxt

In the future it might be better to call setup.py clean on every
setup.py instead of deleting the directory directly.

--Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20100129/9e69bf23/attachment.pgp>

From Ronny.Pfannschmidt at gmx.de  Fri Jan 29 01:05:01 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Fri, 29 Jan 2010 01:05:01 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100129000013.1d80031f@deepthought>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001271444g7bc35a0t299d5ac6ff5c6f59@mail.gmail.com>
	<20100128125454.GC6083@trillke.net>
	<e1ac8ece1001281011k12243cd9y11e524deb893d4d6@mail.gmail.com>
	<1264717443.8246.0.camel@localhost>
	<20100129000013.1d80031f@deepthought>
Message-ID: <1264723501.8246.2.camel@localhost>

On Fri, 2010-01-29 at 00:00 +0100, Adam wrote:
> Ronny Pfannschmidt wrote:
> 
> > On Thu, 2010-01-28 at 18:11 +0000, Joan Miller wrote:
> > > 2010/1/28 holger krekel <holger at merlinux.eu>:
> > > > On Wed, Jan 27, 2010 at 22:44 +0000, Joan Miller wrote:
> > > >> py.cleanup is very usefull, but it also would be usefull to delete the
> > > >> next directories (in bash would be):
> > > >>
> > > >>   $ rm -rf ./build/ ./dist/ ./{src,lib}/*.egg-info
> > > >
> > > > i see how this can make sense.  Any idea how/if this should
> > > > be made configurable?  In my case *.egg-info as a general
> > > > to-be-removed pattern would make sense, i guess.
> > > I agree into a general pattern to delete the eggs info.
> > its actually more tricky, as setup.py develop needs them
> 
> I think it is harmless, as distribute is going to delete the directory
> on setup.py clean:
> 
the idea is not to break packages that got enabled within the users home
via setup.py develop --user

it does harm, as it would break features like entrypoints for those

> http://bitbucket.org/tarek/distribute/issue/122/setuppy-clean-should-delete-sourcestxt
> 
> In the future it might be better to call setup.py clean on every
> setup.py instead of deleting the directory directly.
> 
> --Adam



From peloko45 at gmail.com  Sun Jan 31 18:26:32 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Sun, 31 Jan 2010 17:26:32 +0000
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100127170549.GT6083@trillke.net>
References: <20100127170549.GT6083@trillke.net>
Message-ID: <e1ac8ece1001310926g3ee4ecd3h70a63c55fbccec94@mail.gmail.com>

There is a decorator used in nose to manage errors that should be
raised, which makes it more clear:

http://code.google.com/p/python-nose/source/browse/nose/tools.py#59


2010/1/27 holger krekel <holger at merlinux.eu>:
> Hi all,
>
> if you have anything small regarding py.test that you'd like to see addressed
> please speak up. I plan to release a 1.2.1 end next week.
>


From wmark at hurrikane.de  Sun Jan 31 18:39:10 2010
From: wmark at hurrikane.de (W-Mark Kubacki)
Date: Sun, 31 Jan 2010 18:39:10 +0100
Subject: [py-dev] [patch] greenlet on ARM/linux
In-Reply-To: <20100120202003.GB30119@trillke.net>
References: <9bca96021001200925m36e62d31s51f06e46e6b13535@mail.gmail.com> 
	<9bca96021001200928u12b21c42rdcd507bf9100343@mail.gmail.com> 
	<9bca96021001200932y633eb2b5tf468b898ba03255f@mail.gmail.com> 
	<20100120202003.GB30119@trillke.net>
Message-ID: <9bca96021001310939u974e59aub0e237d824e91474@mail.gmail.com>

2010/1/20 holger krekel <holger at ...>:
> [...]
> Very cool but i am afraid greenlet is not distributed with the
> py lib for a longer time now. So you need to contact other people -
> there was Bob Ippolito and others who did releases. ?If you
> want to grab it and release a new "greenlet" yourself that
> could work and many people would be happy i guess, myself included.

If it is okay with Bob you could move Greenlets to Github (I am
"wmark" there), so users can at least post issues and patches and
create a fork if needed. I will not promise anything, but am willing
to test and verify patches at least on different architectures.

-- 
Mark


From holger at merlinux.eu  Sun Jan 31 21:21:23 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 31 Jan 2010 21:21:23 +0100
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <e1ac8ece1001310926g3ee4ecd3h70a63c55fbccec94@mail.gmail.com>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001310926g3ee4ecd3h70a63c55fbccec94@mail.gmail.com>
Message-ID: <20100131202123.GN6083@trillke.net>

Hi Joan, 

there already is "py.test.raises()" to do it dynamically. 
I am slightly hesitant to add a declarative way.   

is a decorator the only way how nose supports 
"expected-to-raise" assertions?

cheers,
holger

On Sun, Jan 31, 2010 at 17:26 +0000, Joan Miller wrote:
> There is a decorator used in nose to manage errors that should be
> raised, which makes it more clear:
> 
> http://code.google.com/p/python-nose/source/browse/nose/tools.py#59
> 
> 
> 2010/1/27 holger krekel <holger at merlinux.eu>:
> > Hi all,
> >
> > if you have anything small regarding py.test that you'd like to see addressed
> > please speak up. I plan to release a 1.2.1 end next week.
> >
> 

-- 


From peloko45 at gmail.com  Sun Jan 31 21:44:43 2010
From: peloko45 at gmail.com (Joan Miller)
Date: Sun, 31 Jan 2010 20:44:43 +0000
Subject: [py-dev] 1.2.1 planned next week
In-Reply-To: <20100131202123.GN6083@trillke.net>
References: <20100127170549.GT6083@trillke.net>
	<e1ac8ece1001310926g3ee4ecd3h70a63c55fbccec94@mail.gmail.com>
	<20100131202123.GN6083@trillke.net>
Message-ID: <e1ac8ece1001311244n988a224nbde2c95314baf46@mail.gmail.com>

2010/1/31 holger krekel <holger at merlinux.eu>:
> Hi Joan,
>
> there already is "py.test.raises()" to do it dynamically.
> I am slightly hesitant to add a declarative way.
>
> is a decorator the only way how nose supports
> "expected-to-raise" assertions?
It doesn't the only way. That decorator has been added into a one of
last releases.

>
> cheers,
> holger
>
> On Sun, Jan 31, 2010 at 17:26 +0000, Joan Miller wrote:
>> There is a decorator used in nose to manage errors that should be
>> raised, which makes it more clear:
>>
>> http://code.google.com/p/python-nose/source/browse/nose/tools.py#59
>>
>>
>> 2010/1/27 holger krekel <holger at merlinux.eu>:
>> > Hi all,
>> >
>> > if you have anything small regarding py.test that you'd like to see addressed
>> > please speak up. I plan to release a 1.2.1 end next week.
>> >
>>
>
> --
>