From michele.simionato at gmail.com Sun Jul 10 11:02:40 2005 From: michele.simionato at gmail.com (Michele Simionato) Date: Sun, 10 Jul 2005 11:02:40 +0200 Subject: [py-dev] is there an easy-to-install py.test release for Windows? Message-ID: <4edc17eb050710020246c61fcf@mail.gmail.com> The subject says it all. I would like to install py.test on Windows without having to install subversion first. Michele Simionato From grig at gheorghiu.net Sun Jul 10 20:54:40 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Sun, 10 Jul 2005 11:54:40 -0700 (PDT) Subject: [py-dev] is there an easy-to-install py.test release for Windows? In-Reply-To: <4edc17eb050710020246c61fcf@mail.gmail.com> Message-ID: <20050710185440.84563.qmail@web54506.mail.yahoo.com> --- Michele Simionato wrote: > The subject says it all. I would like to install py.test on Windows > without > having to install subversion first. > To the best of my knowledge, the py library has not been released on any platform yet. TortoiseSVN is a breeze to work with on Windows, so why don't you give that a try :-) ? Also, once you check out the py library files, you can install it on Windows via the setup.py script. It should add py.test to your PATH, but for that you will have to open a new command prompt window after the install. Grig From dstanek at dstanek.com Mon Jul 11 06:10:38 2005 From: dstanek at dstanek.com (David Stanek) Date: Mon, 11 Jul 2005 00:10:38 -0400 Subject: [py-dev] is there an easy-to-install py.test release for Windows? In-Reply-To: <4edc17eb050710020246c61fcf@mail.gmail.com> References: <4edc17eb050710020246c61fcf@mail.gmail.com> Message-ID: <20050711041038.GA7862@goliath.hsd1.oh.comcast.net> On Sun, Jul 10, 2005 at 11:02:40AM +0200, Michele Simionato wrote: > The subject says it all. I would like to install py.test on Windows without > having to install subversion first. No official release yet, but I believe you can download the code from - http://codespeak.net/download/py/. -- David Stanek www.roninds.net GPG keyID #6272EDAF on http://pgp.mit.edu Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hpk at trillke.net Mon Jul 11 10:16:28 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 11 Jul 2005 10:16:28 +0200 Subject: [py-dev] is there an easy-to-install py.test release for Windows? In-Reply-To: <20050711041038.GA7862@goliath.hsd1.oh.comcast.net> References: <4edc17eb050710020246c61fcf@mail.gmail.com> <20050711041038.GA7862@goliath.hsd1.oh.comcast.net> Message-ID: <20050711081628.GM28807@solar.trillke.net> Hi Michele, hi David, On Mon, Jul 11, 2005 at 00:10 -0400, David Stanek wrote: > On Sun, Jul 10, 2005 at 11:02:40AM +0200, Michele Simionato wrote: > > The subject says it all. I would like to install py.test on Windows without > > having to install subversion first. > > No official release yet, but I believe you can download the > code from - http://codespeak.net/download/py/. Yes, i just put up a current snapshot as 0.8.0-alpha2 onto that location. Find it here: http://codespeak.net/download/py/py-0.8.0-alpha2.tar.gz Don't expect greenlets to easily work on windows unless you distutils can compile c-extensions from source on your machine. cheers, holger P.S.: i am finally back after more than two weeks of pypy-sprinting and conferencing ... From michele.simionato at gmail.com Tue Jul 12 13:09:08 2005 From: michele.simionato at gmail.com (Michele Simionato) Date: Tue, 12 Jul 2005 13:09:08 +0200 Subject: [py-dev] is there an easy-to-install py.test release for Windows? In-Reply-To: <20050711081628.GM28807@solar.trillke.net> References: <4edc17eb050710020246c61fcf@mail.gmail.com> <20050711041038.GA7862@goliath.hsd1.oh.comcast.net> <20050711081628.GM28807@solar.trillke.net> Message-ID: <4edc17eb05071204093eaf42f4@mail.gmail.com> Thanks, I will give to it a try. I am preparing a course about automatic testing to people using Windows (people which are not real programmers). Teaching py.test is easier since there is no OO cruft. So I am considering to teach it instead of unittest. An important requisite for my target of users is a seemless installation. Michele Simionato From hpk at trillke.net Tue Jul 12 13:30:03 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 12 Jul 2005 13:30:03 +0200 Subject: [py-dev] is there an easy-to-install py.test release for Windows? In-Reply-To: <4edc17eb05071204093eaf42f4@mail.gmail.com> References: <4edc17eb050710020246c61fcf@mail.gmail.com> <20050711041038.GA7862@goliath.hsd1.oh.comcast.net> <20050711081628.GM28807@solar.trillke.net> <4edc17eb05071204093eaf42f4@mail.gmail.com> Message-ID: <20050712113003.GT28807@solar.trillke.net> Hi Michele, On Tue, Jul 12, 2005 at 13:09 +0200, Michele Simionato wrote: > Thanks, I will give to it a try. I am preparing a course about automatic testing > to people using Windows (people which are not real programmers). Teaching > py.test is easier since there is no OO cruft. So I am considering to teach it > instead of unittest. An important requisite for my target of users is a > seemless installation. Sometimes i dream of someone who would do a real windows GUI frontend similar to TortoiseSVN's way of having right-click-directory to test and get different views on the errors. This real thing would also have a real windows installer, of course. It's great, btw, that you consider using py.test for teaching automated testing courses. There were some fruitful discussions at EuroPython about moving towards more unified testing approaches in Python, btw. A couple of developer groups see the need but as always it's a matter of actually getting to do it. I guess that a one-week sprint with testing people from some major python projects working together would accelerate such a development of a unified testing approach considerably. cheers, holger From dangoor at gmail.com Tue Jul 12 16:19:31 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Tue, 12 Jul 2005 10:19:31 -0400 Subject: [py-dev] any chance of py working from a zip? Message-ID: <3f085ecd050712071968218f04@mail.gmail.com> I would like to get py.test (in particular) working from an "egg" (a zip file with metadata) for easy distribution with other packages that are tested with py.test. Creating the egg required a trivial change to py/misc/_dist.py. However, attempting to run py.test fails for me File "build/bdist.darwin-8.1.0-Power_Macintosh/egg/py/test/config.py", line 91, in loadconfig File "build/bdist.darwin-8.1.0-Power_Macintosh/egg/py/test/config.py", line 206, in importconfig File "build/bdist.darwin-8.1.0-Power_Macintosh/egg/py/path/local/local.py", line 357, in pyimport py.error.ENOENT: [No such file or directory]: /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py-0.8.0_alpha2-py2.4.egg/py/test/defaultconftest.py It's attempting to do a file lookup on something within py-0.8.0_alpha2-py2.4.egg, which is not going to work since that's a zip file. Am I correct in assuming that the package handling tricks within py basically mean that py.test simply won't be able to run from within a zipfile? If it's just the configuration part that has an issue, that may be a manageable problem to solve, but I wanted to see what people here thought, since I haven't looked deeply at the packaging of py. Thanks! Kevin From hpk at trillke.net Tue Jul 12 16:30:37 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 12 Jul 2005 16:30:37 +0200 Subject: [py-dev] any chance of py working from a zip? In-Reply-To: <3f085ecd050712071968218f04@mail.gmail.com> References: <3f085ecd050712071968218f04@mail.gmail.com> Message-ID: <20050712143037.GC7049@solar.trillke.net> Hi Kevin, On Tue, Jul 12, 2005 at 10:19 -0400, Kevin Dangoor wrote: > I would like to get py.test (in particular) working from an "egg" (a > zip file with metadata) for easy distribution with other packages that > are tested with py.test. Creating the egg required a trivial change to > py/misc/_dist.py. However, attempting to run py.test fails for me > > File "build/bdist.darwin-8.1.0-Power_Macintosh/egg/py/test/config.py", > line 91, in loadconfig > File "build/bdist.darwin-8.1.0-Power_Macintosh/egg/py/test/config.py", > line 206, in importconfig > File "build/bdist.darwin-8.1.0-Power_Macintosh/egg/py/path/local/local.py", > line 357, in pyimport > py.error.ENOENT: [No such file or directory]: > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py-0.8.0_alpha2-py2.4.egg/py/test/defaultconftest.py > > It's attempting to do a file lookup on something within > py-0.8.0_alpha2-py2.4.egg, which is not going to work since that's a > zip file. > > Am I correct in assuming that the package handling tricks within py > basically mean that py.test simply won't be able to run from within a > zipfile? It's not really about tricks here. It's the usual problem of accessing data (and in this case a default conftest file which happens to come with the distribution) from an installed package. > If it's just the configuration part that has an issue, that may be a > manageable problem to solve, but I wanted to see what people here > thought, since I haven't looked deeply at the packaging of py. We definitely want a uniform way to get to resources from within a running program. So far one does something like: mypath = py.magic.autopath() resource_in_my_dir = mypath.dirpath("somefile.txt") which returns a path to the 'somefile.txt' file residing in the same directory as the module where the above code lives. autopath() currently returns a local path object and for imports from zip-files it should rather return a "Zip-Path" but unfortunately this hasn't been written yet (it shouldn't be hard, though, compared to the subversion WC and URL paths already implemented). Where is the summer of code when you need it :-) cheers, holger From dangoor at gmail.com Tue Jul 12 18:01:37 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Tue, 12 Jul 2005 12:01:37 -0400 Subject: [py-dev] any chance of py working from a zip? In-Reply-To: <20050712143037.GC7049@solar.trillke.net> References: <3f085ecd050712071968218f04@mail.gmail.com> <20050712143037.GC7049@solar.trillke.net> Message-ID: <3f085ecd05071209012ae6da5d@mail.gmail.com> Hi Holger, On 7/12/05, holger krekel wrote: > We definitely want a uniform way to get to resources from within > a running program. So far one does something like: > > mypath = py.magic.autopath() > resource_in_my_dir = mypath.dirpath("somefile.txt") > > which returns a path to the 'somefile.txt' file residing in the same > directory as the module where the above code lives. > autopath() currently returns a local path object and for > imports from zip-files it should rather return a "Zip-Path" > but unfortunately this hasn't been written yet (it shouldn't > be hard, though, compared to the subversion WC and URL paths > already implemented). Where is the summer of code when you > need it :-) Actually, I think you're in luck! This has already been written as part of setuptools. http://peak.telecommunity.com/DevCenter/setuptools Specifically, http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources The pkg_resources module provides some nice mechanisms for uniformly getting at your package data. setuptools also provides nicer options for including your data in distributions. I believe you could include pkg_resources without introducing a dependency on setuptools, but setuptools is really not a bad dependency to have. Does py.test require access to things that would be in the zipfile beyond the default configuration? I'm curious to know how much work would be required to get py.test running from a zip... Kevin From dangoor at gmail.com Tue Jul 12 18:28:55 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Tue, 12 Jul 2005 12:28:55 -0400 Subject: [py-dev] any chance of py working from a zip? In-Reply-To: <3f085ecd05071209012ae6da5d@mail.gmail.com> References: <3f085ecd050712071968218f04@mail.gmail.com> <20050712143037.GC7049@solar.trillke.net> <3f085ecd05071209012ae6da5d@mail.gmail.com> Message-ID: <3f085ecd05071209285a350761@mail.gmail.com> On 7/12/05, Kevin Dangoor wrote: > Does py.test require access to things that would be in the zipfile > beyond the default configuration? I'm curious to know how much work > would be required to get py.test running from a zip... Actually, setuptools conveniently answers this question for me. py.initpkg: module references __file__ py.initpkg: module references __path__ py.code.code: module references __path__ py.code.source: module MAY be using inspect.getsource py.compat.doctest: module references __file__ py.compat.doctest: module MAY be using inspect.getsourcefile py.compat.testing._findpy: module references __file__ py.compat.testing.test_doctest2: module references __file__ py.execnet.register: module references __file__ py.execnet.register: module MAY be using inspect.getsource py.execnet.register: module MAY be using inspect.trace py.execnet.testing.test_gateway: module MAY be using inspect.getsource py.magic.autopath: module references __file__ py.magic.autopath: module references __path__ py.magic.greenlet: module references __file__ py.magic.testing.test_autopath: module references __file__ py.misc._dist: module references __file__ py.misc.testing.test_initpkg: module references __file__ py.path.common: module references __file__ py.path.common: module references __path__ py.path.extpy.extpy: module references __file__ py.path.extpy.extpy: module MAY be using inspect.findsource py.path.local.local: module references __file__ py.test.item: module MAY be using inspect.stack py.test.terminal.terminal: module references __file__ py.test.terminal.terminal: module MAY be using inspect.getsource Kevin From hpk at trillke.net Tue Jul 12 18:41:17 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 12 Jul 2005 18:41:17 +0200 Subject: [py-dev] any chance of py working from a zip? In-Reply-To: <3f085ecd05071209012ae6da5d@mail.gmail.com> References: <3f085ecd050712071968218f04@mail.gmail.com> <20050712143037.GC7049@solar.trillke.net> <3f085ecd05071209012ae6da5d@mail.gmail.com> Message-ID: <20050712164117.GJ7049@solar.trillke.net> Hi Kevin, On Tue, Jul 12, 2005 at 12:01 -0400, Kevin Dangoor wrote: > On 7/12/05, holger krekel wrote: > > We definitely want a uniform way to get to resources from within > > a running program. So far one does something like: > > > > mypath = py.magic.autopath() > > resource_in_my_dir = mypath.dirpath("somefile.txt") > > > > which returns a path to the 'somefile.txt' file residing in the same > > directory as the module where the above code lives. > > autopath() currently returns a local path object and for > > imports from zip-files it should rather return a "Zip-Path" > > but unfortunately this hasn't been written yet (it shouldn't > > be hard, though, compared to the subversion WC and URL paths > > already implemented). Where is the summer of code when you > > need it :-) > > Actually, I think you're in luck! This has already been written as > part of setuptools. > > http://peak.telecommunity.com/DevCenter/setuptools > > Specifically, > > http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources Interesting. > The pkg_resources module provides some nice mechanisms for uniformly > getting at your package data. setuptools also provides nicer options > for including your data in distributions. I think we are talking about different API levels here. I want callers of py.magic.autopath() to stay unaware of distribution details and it should thus really return a path-like object (the py lib has uniform "Path" implementations in py.path.*). Return a Zip-Path from py.magic.autopath() will be quite trivial once we have the implementation. > Does py.test require access to things that would be in the zipfile > beyond the default configuration? I'm curious to know how much work > would be required to get py.test running from a zip... You can assume that py.test has arbitrary resources, e.g. the tkinter-frontend (py.test --tkinter) has some graphical resources. cheers, holger From dangoor at gmail.com Tue Jul 12 18:56:34 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Tue, 12 Jul 2005 12:56:34 -0400 Subject: [py-dev] any chance of py working from a zip? In-Reply-To: <20050712164117.GJ7049@solar.trillke.net> References: <3f085ecd050712071968218f04@mail.gmail.com> <20050712143037.GC7049@solar.trillke.net> <3f085ecd05071209012ae6da5d@mail.gmail.com> <20050712164117.GJ7049@solar.trillke.net> Message-ID: <3f085ecd05071209565844c7bf@mail.gmail.com> On 7/12/05, holger krekel wrote: > I think we are talking about different API levels here. I > want callers of py.magic.autopath() to stay unaware of > distribution details and it should thus really return a > path-like object (the py lib has uniform "Path" > implementations in py.path.*). Return a Zip-Path from > py.magic.autopath() will be quite trivial once we have > the implementation. Aha... You're right, we were talking about different API levels. I wasn't thinking about py's path abstraction that way. > > > Does py.test require access to things that would be in the zipfile > > beyond the default configuration? I'm curious to know how much work > > would be required to get py.test running from a zip... > > You can assume that py.test has arbitrary resources, e.g. the > tkinter-frontend (py.test --tkinter) has some graphical > resources. Yep, I noticed that from the setuptools output. Kevin From grig at gheorghiu.net Wed Jul 13 17:11:05 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Wed, 13 Jul 2005 08:11:05 -0700 (PDT) Subject: [py-dev] Unicode support in py.log Message-ID: <20050713151105.51357.qmail@web54509.mail.yahoo.com> I was using the default STDOUT consumer in py.log when I ran into a problem printing strings that contain non-ASCII characters. I think we should modify at a minimum the 'content' method of the Message class in producer.py so that it uses unicode as opposed to str. Here's what I did temporarily to get past my problem: def content(self): return " ".join(map(unicode, self.args)).encode('utf-8') Of course, the encoding should be configurable, but I'm not sure if it's best to have it as a global variable in producer.py or some other way. Grig From hpk at trillke.net Wed Jul 13 17:19:10 2005 From: hpk at trillke.net (holger krekel) Date: Wed, 13 Jul 2005 17:19:10 +0200 Subject: [py-dev] Unicode support in py.log In-Reply-To: <20050713151105.51357.qmail@web54509.mail.yahoo.com> References: <20050713151105.51357.qmail@web54509.mail.yahoo.com> Message-ID: <20050713151910.GD12091@solar.trillke.net> Hi Grig! On Wed, Jul 13, 2005 at 08:11 -0700, Grig Gheorghiu wrote: > I was using the default STDOUT consumer in py.log when I ran into a > problem printing strings that contain non-ASCII characters. I think we > should modify at a minimum the 'content' method of the Message class in > producer.py so that it uses unicode as opposed to str. Here's what I > did temporarily to get past my problem: > > def content(self): > return " ".join(map(unicode, self.args)).encode('utf-8') > > Of course, the encoding should be configurable, but I'm not sure if > it's best to have it as a global variable in producer.py or some other > way. Hum, i am not sure about the best way to go about unicode handling in py.log context. I guess that content() should always return a unicode object and the log consumer should care about encodings. And the default STDOUT/STDERR consumer should convert to the system encoding. If a user wants something different he has to register an appropriate consumer. makes sense? holger From grig at gheorghiu.net Wed Jul 13 17:25:08 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Wed, 13 Jul 2005 08:25:08 -0700 (PDT) Subject: [py-dev] Unicode support in py.log In-Reply-To: <20050713151910.GD12091@solar.trillke.net> Message-ID: <20050713152508.72011.qmail@web54510.mail.yahoo.com> Hi, Holger --- holger krekel wrote: > Hi Grig! > > On Wed, Jul 13, 2005 at 08:11 -0700, Grig Gheorghiu wrote: > > I was using the default STDOUT consumer in py.log when I ran into a > > problem printing strings that contain non-ASCII characters. I think > we > > should modify at a minimum the 'content' method of the Message > class in > > producer.py so that it uses unicode as opposed to str. Here's what > I > > did temporarily to get past my problem: > > > > def content(self): > > return " ".join(map(unicode, self.args)).encode('utf-8') > > > > Of course, the encoding should be configurable, but I'm not sure if > > it's best to have it as a global variable in producer.py or some > other > > way. > > Hum, i am not sure about the best way to go about unicode handling in > > py.log context. I guess that content() should always return > a unicode object and the log consumer should care about encodings. > And the default STDOUT/STDERR consumer should convert to the system > encoding. If a user wants something different he has to register > an appropriate consumer. makes sense? > > holger > Yes, that makes a lot of sense. I'll give it a shot and I'll let you know if I run into any more issues. Grig From grig at gheorghiu.net Wed Jul 13 17:49:58 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Wed, 13 Jul 2005 08:49:58 -0700 (PDT) Subject: [py-dev] Unicode support in py.log In-Reply-To: <20050713151910.GD12091@solar.trillke.net> Message-ID: <20050713154958.97089.qmail@web54506.mail.yahoo.com> --- holger krekel wrote: > Hi Grig! > > On Wed, Jul 13, 2005 at 08:11 -0700, Grig Gheorghiu wrote: > > I was using the default STDOUT consumer in py.log when I ran into a > > problem printing strings that contain non-ASCII characters. I think > we > > should modify at a minimum the 'content' method of the Message > class in > > producer.py so that it uses unicode as opposed to str. Here's what > I > > did temporarily to get past my problem: > > > > def content(self): > > return " ".join(map(unicode, self.args)).encode('utf-8') > > > > Of course, the encoding should be configurable, but I'm not sure if > > it's best to have it as a global variable in producer.py or some > other > > way. > > Hum, i am not sure about the best way to go about unicode handling in > > py.log context. I guess that content() should always return > a unicode object and the log consumer should care about encodings. > And the default STDOUT/STDERR consumer should convert to the system > encoding. If a user wants something different he has to register > an appropriate consumer. makes sense? It seems that if you call str(msg) you get back a string object and not a unicode object, even if the __str__ method of the Message class returns a unicode object. So the solution I found was to define a __unicode__ method for the Message class. Consumers will have to call unicode(msg).encode('desired_encoding'). At this point, the __str__ method is not doing anything useful, unless we do some default encoding ourselves. Here's how I modified the Message class, with both content() and prefix() now returning unicode objects: class Message(object): def __init__(self, keywords, args): self.keywords = keywords self.args = args def content(self): return " ".join(map(unicode, self.args)) def prefix(self): return "[%s] " % (u":".join(self.keywords)) def __unicode__(self): return self.prefix() + self.content() def __str__(self): s = self.prefix() + self.content() return s.encode('utf-8') If we leave __str__ as defined above, consumers will still be able to call str(msg) and things will work, so we're not really enforcing the policy that consumers are in charge of encoding. So maybe we should just drop the __str__ method? Grig From grig at gheorghiu.net Mon Jul 18 19:33:24 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Mon, 18 Jul 2005 10:33:24 -0700 (PDT) Subject: [py-dev] Running only previously failing tests Message-ID: <20050718173324.73115.qmail@web54505.mail.yahoo.com> I thought this was possible via 'py.test --session=terminal' for example, but when I do that all the tests are run, not only the ones that were previously failing. Am I doing something wrong? Thanks, Grig From hpk at trillke.net Mon Jul 18 19:54:33 2005 From: hpk at trillke.net (holger krekel) Date: Mon, 18 Jul 2005 19:54:33 +0200 Subject: [py-dev] Running only previously failing tests In-Reply-To: <20050718173324.73115.qmail@web54505.mail.yahoo.com> References: <20050718173324.73115.qmail@web54505.mail.yahoo.com> Message-ID: <20050718175433.GC9782@solar.trillke.net> Hi Grig! On Mon, Jul 18, 2005 at 10:33 -0700, Grig Gheorghiu wrote: > I thought this was possible via 'py.test --session=terminal' for > example, but when I do that all the tests are run, not only the ones > that were previously failing. Am I doing something wrong? Only the '--looponfailing' option does what you want. It keeps the frontend process looping and waiting for file changes in the project. On such changes the failing tests are re-run in a second process. The backend process reports to the frontend process the set of failing tests so that they can be memorized by the frontend process. cheers, holger From grig at gheorghiu.net Mon Jul 18 22:26:48 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Mon, 18 Jul 2005 13:26:48 -0700 (PDT) Subject: [py-dev] Running only previously failing tests In-Reply-To: <20050718201007.GD9782@solar.trillke.net> Message-ID: <20050718202648.85340.qmail@web54506.mail.yahoo.com> --- holger krekel wrote: > On Mon, Jul 18, 2005 at 10:57 -0700, Grig Gheorghiu wrote: > > --- holger krekel wrote: > > > > > Hi Grig! > > > > > > On Mon, Jul 18, 2005 at 10:33 -0700, Grig Gheorghiu wrote: > > > > I thought this was possible via 'py.test --session=terminal' > for > > > > example, but when I do that all the tests are run, not only the > > > ones > > > > that were previously failing. Am I doing something wrong? > > > > > > Only the '--looponfailing' option does what you want. It keeps > > > the frontend process looping and waiting for file changes > > > in the project. On such changes the failing tests are re-run > > > in a second process. The backend process reports to the > > > frontend process the set of failing tests so that they > > > can be memorized by the frontend process. > > > > OK, I knew about looponfailing....But as you say, looponfailing > watches > > for changes in all files. I thought there's an easier way to just > tell > > py.test to run previously failing tests. I guess it's a feature to > add > > to the list? > > Yes, it is. It requires some storage mechanism for py.test (and the > py lib > in general), for example a '.' directory in the home-directory of the > user. > But it should work for win32 as well, of course. I am not sure how > you can construct a user specific directory. Moreover, it should be > safe > against concurrent accesses e.g. from test sessions running at the > same > time. This is not super-hard but it requires some thought and > platform > knowledge. Once we have such a mechanism it becomes rather easy to > rerun previously failing tests. > Hi, Holger There are 2 environment variables in Windows that together give you a user-specific directory: HOMEDRIVE and HOMEPATH. So that should not be a problem. I think the harder part is the concurrent aspect. But I'm sure we can figure something out on Windows once we have a reference implementation on Unix. Grig From grig at gheorghiu.net Mon Jul 18 22:54:36 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Mon, 18 Jul 2005 13:54:36 -0700 (PDT) Subject: [py-dev] svn diff for producer.py and consumer.py Message-ID: <20050718205436.85911.qmail@web54502.mail.yahoo.com> Holger, I'm including 2 diffs for consumer.py and producer.py. I added some initial unicode support, with a default encoding of 'utf-8'. The only other modification is that the prefix() method of a Message only uses square brackets when there are actual keywords to be printed. If you instantiate a log object via log = py.log.Producer(""), then log('blah') will now produce 'blah', not '[] blah'. I didn't want to commit these changes, since you may have other ideas on the unicode stuff. Grig # svn diff producer.py Index: producer.py =================================================================== --- producer.py (revision 14743) +++ producer.py (working copy) @@ -16,14 +16,20 @@ self.args = args def content(self): - return " ".join(map(str, self.args)) + return " ".join(map(unicode, self.args)) - def prefix(self): - return "[%s] " % (":".join(self.keywords)) + def prefix(self): + if not self.keywords: + return u"" + return "[%s] " % (u":".join(self.keywords)) def __str__(self): - return self.prefix() + self.content() + s = self.prefix() + self.content() + return s.encode('utf-8') + def __unicode__(self): + return self.prefix() + self.content() + class Producer(object): """ Log producer API which sends messages to be logged to a 'consumer' object, which then prints them to stdout, @@ -71,6 +77,6 @@ Producer.keywords2consumer.update(state) def default_consumer(msg): - print str(msg) + print unicode(msg).encode('utf-8') Producer.keywords2consumer['default'] = default_consumer # svn diff consumer.py Index: consumer.py =================================================================== --- consumer.py (revision 14743) +++ consumer.py (working copy) @@ -1,6 +1,8 @@ import py import sys +DEFAULT_ENCODING = 'utf-8' + class File(object): def __init__(self, f): assert hasattr(f, 'write') @@ -8,7 +10,7 @@ self._file = f def __call__(self, msg): - print >>self._file, str(msg) + print >>self._file, unicode(msg).encode(DEFAULT_ENCODING) class Path(File): def __init__(self, filename, append=False): @@ -17,10 +19,10 @@ super(Path, self).__init__(f) def STDOUT(msg): - print >>sys.stdout, str(msg) + print >>sys.stdout, unicode(msg).encode(DEFAULT_ENCODING) def STDERR(msg): - print >>sys.stderr, str(msg) + print >>sys.stderr, unicode(msg).encode(DEFAULT_ENCODING) def setconsumer(keywords, consumer): # normalize to tuples From odonian at gmail.com Tue Jul 19 06:38:53 2005 From: odonian at gmail.com (odonian at gmail.com) Date: Tue, 19 Jul 2005 00:38:53 -0400 Subject: [py-dev] py.test error with cygwin update Message-ID: <8b9a72d3050718213836ad3f83@mail.gmail.com> I've been happily using py.test for about two months without problems with an older version of cygwin (maybe 3-4 months old; sorry, don't have the version number) and python 2.3.4. Just recently I updated the cygwin environment, and now py.test keeps failing; I have tried re-installing the py lib, re-installing cygwin, and tried different versions of python (2.3.4, 2.4.1). But this error keeps coming up when running py.test, regardless of any other command-line arguments (i.e. whether it's run in test collection mode, or fed a specific test file, this error shows up): Traceback (most recent call last): File "/usr/bin/py.test", line 4, in ? py.test.cmdline.main() File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 8, in main config, args = py.test.Config.parse(py.std.sys.argv[1:]) File "/usr/lib/python2.4/site-packages/py/test/config.py", line 60, in parse configpaths = guessconfigpaths(*getanchorpaths(args)) File "/usr/lib/python2.4/site-packages/py/test/config.py", line 183, in guessconfigpaths if x.check(file=1): File "/usr/lib/python2.4/site-packages/py/path/common.py", line 96, in check return self.Checkers(self)._evaluate(kw) File "/usr/lib/python2.4/site-packages/py/path/common.py", line 69, in _evaluate if bool(value) ^ bool(meth()) ^ invert: File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 38, in file return stat.S_ISREG(self._stat().st_mode) File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 29, in _stat self._statcache = self.path.stat() File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 283, in stat return self._callex(os.stat, self.strpath) File "/usr/lib/python2.4/site-packages/py/path/common.py", line 207, in _callex cls = py.error._geterrnoclass(errno) File "/usr/lib/python2.4/site-packages/py/misc/error.py", line 45, in _geterrnoclass clsname = py.std.errno.errorcode[eno] KeyError: 136 Since this didn't show up before, ever, I'm guessing paths are somehow handled differently in newer cygwin versions, but hard to imagine why it would change that much. I have tried catching the above particular KeyError for the errorcode dictionary, but that only causes another problem elsewhere. Any help would be appreciated, S.A. From hpk at trillke.net Tue Jul 19 12:21:51 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 19 Jul 2005 12:21:51 +0200 Subject: [py-dev] py.test error with cygwin update In-Reply-To: <8b9a72d3050718213836ad3f83@mail.gmail.com> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> Message-ID: <20050719102151.GB18466@solar.trillke.net> Hi, On Tue, Jul 19, 2005 at 00:38 -0400, odonian at gmail.com wrote: > I've been happily using py.test for about two months without problems > with an older version of cygwin (maybe 3-4 months old; sorry, don't > have the version number) and python 2.3.4. good! > Just recently I updated the cygwin environment, and now py.test keeps > failing; I have tried re-installing the py lib, re-installing cygwin, > and tried different versions of python (2.3.4, 2.4.1). But this error > keeps coming up when running py.test, regardless of any other > command-line arguments (i.e. whether it's run in test collection mode, > or fed a specific test file, this error shows up): > > Traceback (most recent call last): > File "/usr/bin/py.test", line 4, in ? > py.test.cmdline.main() > File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 8, in main > config, args = py.test.Config.parse(py.std.sys.argv[1:]) > File "/usr/lib/python2.4/site-packages/py/test/config.py", line 60, in parse > configpaths = guessconfigpaths(*getanchorpaths(args)) > File "/usr/lib/python2.4/site-packages/py/test/config.py", line 183, > in guessconfigpaths > if x.check(file=1): > File "/usr/lib/python2.4/site-packages/py/path/common.py", line 96, in check > return self.Checkers(self)._evaluate(kw) > File "/usr/lib/python2.4/site-packages/py/path/common.py", line 69, > in _evaluate > if bool(value) ^ bool(meth()) ^ invert: > File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line > 38, in file > return stat.S_ISREG(self._stat().st_mode) > File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line > 29, in _stat > self._statcache = self.path.stat() > File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line > 283, in stat > return self._callex(os.stat, self.strpath) > File "/usr/lib/python2.4/site-packages/py/path/common.py", line 207, > in _callex > cls = py.error._geterrnoclass(errno) > File "/usr/lib/python2.4/site-packages/py/misc/error.py", line 45, > in _geterrnoclass > clsname = py.std.errno.errorcode[eno] > KeyError: 136 It seems that this is an error code that is not defined by Python's errno module. We should provide a default Error class like "UnknownErrno136" in case we can't discover it from the errorcode module. I have just commited something along these lines. > Since this didn't show up before, ever, I'm guessing paths are somehow > handled differently in newer cygwin versions, but hard to imagine why > it would change that much. I have tried catching the above particular > KeyError for the errorcode dictionary, but that only causes another > problem elsewhere. Any help would be appreciated, The error should propagate because it indicates a real problem. Once we have a proper error and know which os-level operation actually failed we should be further. Can you 'svn up', reinstall and report about the error/traceback again? cheers, holger From odonian at gmail.com Tue Jul 19 14:44:11 2005 From: odonian at gmail.com (odonian at gmail.com) Date: Tue, 19 Jul 2005 08:44:11 -0400 Subject: [py-dev] py.test error with cygwin update In-Reply-To: <20050719102151.GB18466@solar.trillke.net> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> <20050719102151.GB18466@solar.trillke.net> Message-ID: <8b9a72d3050719054421d29ba2@mail.gmail.com> Hi, Thanks for the quick help; I did svn up, then setup.py build and install. A different traceback now appears: Traceback (most recent call last): File "/usr/bin/py.test", line 4, in ? py.test.cmdline.main() File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 8, in main config, args = py.test.Config.parse(py.std.sys.argv[1:]) File "/usr/lib/python2.4/site-packages/py/test/config.py", line 60, in parse configpaths = guessconfigpaths(*getanchorpaths(args)) File "/usr/lib/python2.4/site-packages/py/test/config.py", line 183, in guessconfigpaths if x.check(file=1): File "/usr/lib/python2.4/site-packages/py/path/common.py", line 96, in check return self.Checkers(self)._evaluate(kw) File "/usr/lib/python2.4/site-packages/py/path/common.py", line 69, in _evaluate if bool(value) ^ bool(meth()) ^ invert: File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 38, in file return stat.S_ISREG(self._stat().st_mode) File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 29, in _stat self._statcache = self.path.stat() File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 283, in stat return self._callex(os.stat, self.strpath) File "/usr/lib/python2.4/site-packages/py/path/common.py", line 215, in _callex raise cls, value py.error.UnknownErrno136: [No such host or network path]: stat('//conftest.py',) Any ideas? Thanks in advance, S.A. On 7/19/05, holger krekel wrote: > Hi, > > On Tue, Jul 19, 2005 at 00:38 -0400, odonian at gmail.com wrote: > > I've been happily using py.test for about two months without problems > > with an older version of cygwin (maybe 3-4 months old; sorry, don't > > have the version number) and python 2.3.4. > > good! > > > Just recently I updated the cygwin environment, and now py.test keeps > > failing; I have tried re-installing the py lib, re-installing cygwin, > > and tried different versions of python (2.3.4, 2.4.1). But this error > > keeps coming up when running py.test, regardless of any other > > command-line arguments (i.e. whether it's run in test collection mode, > > or fed a specific test file, this error shows up): > > > > Traceback (most recent call last): > > File "/usr/bin/py.test", line 4, in ? > > py.test.cmdline.main() > > File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 8, in main > > config, args = py.test.Config.parse(py.std.sys.argv[1:]) > > File "/usr/lib/python2.4/site-packages/py/test/config.py", line 60, in parse > > configpaths = guessconfigpaths(*getanchorpaths(args)) > > File "/usr/lib/python2.4/site-packages/py/test/config.py", line 183, > > in guessconfigpaths > > if x.check(file=1): > > File "/usr/lib/python2.4/site-packages/py/path/common.py", line 96, in check > > return self.Checkers(self)._evaluate(kw) > > File "/usr/lib/python2.4/site-packages/py/path/common.py", line 69, > > in _evaluate > > if bool(value) ^ bool(meth()) ^ invert: > > File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line > > 38, in file > > return stat.S_ISREG(self._stat().st_mode) > > File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line > > 29, in _stat > > self._statcache = self.path.stat() > > File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line > > 283, in stat > > return self._callex(os.stat, self.strpath) > > File "/usr/lib/python2.4/site-packages/py/path/common.py", line 207, > > in _callex > > cls = py.error._geterrnoclass(errno) > > File "/usr/lib/python2.4/site-packages/py/misc/error.py", line 45, > > in _geterrnoclass > > clsname = py.std.errno.errorcode[eno] > > KeyError: 136 > > It seems that this is an error code that is not defined by > Python's errno module. We should provide a default > Error class like "UnknownErrno136" in case we can't discover > it from the errorcode module. I have just commited something > along these lines. > > > Since this didn't show up before, ever, I'm guessing paths are somehow > > handled differently in newer cygwin versions, but hard to imagine why > > it would change that much. I have tried catching the above particular > > KeyError for the errorcode dictionary, but that only causes another > > problem elsewhere. Any help would be appreciated, > > The error should propagate because it indicates a real problem. > Once we have a proper error and know which os-level operation > actually failed we should be further. Can you 'svn up', > reinstall and report about the error/traceback again? > > cheers, > > holger > From dstanek at dstanek.com Tue Jul 19 18:18:23 2005 From: dstanek at dstanek.com (David Stanek) Date: Tue, 19 Jul 2005 12:18:23 -0400 (EDT) Subject: [py-dev] py.test error with cygwin update In-Reply-To: <20050719102151.GB18466@solar.trillke.net> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> <20050719102151.GB18466@solar.trillke.net> Message-ID: <32312.207.58.192.150.1121789903.squirrel@207.58.192.150> > It seems that this is an error code that is not defined by > Python's errno module. We should provide a default > Error class like "UnknownErrno136" in case we can't discover > it from the errorcode module. I have just commited something > along these lines. > > The error should propagate because it indicates a real problem. > Once we have a proper error and know which os-level operation > actually failed we should be further. Can you 'svn up', > reinstall and report about the error/traceback again? > Hello, Is there a reason why you chose a dynamically created class instead of a concrete UnknownErrno class? Or would it be useful to have a different base class for UnknownErrno## classes so that they can be caught separately? -- David Stanek From hpk at trillke.net Tue Jul 19 18:52:15 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 19 Jul 2005 18:52:15 +0200 Subject: [py-dev] py.test error with cygwin update In-Reply-To: <32312.207.58.192.150.1121789903.squirrel@207.58.192.150> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> <20050719102151.GB18466@solar.trillke.net> <32312.207.58.192.150.1121789903.squirrel@207.58.192.150> Message-ID: <20050719165215.GN18466@solar.trillke.net> Hi David, On Tue, Jul 19, 2005 at 12:18 -0400, David Stanek wrote: > > It seems that this is an error code that is not defined by > > Python's errno module. We should provide a default > > Error class like "UnknownErrno136" in case we can't discover > > it from the errorcode module. I have just commited something > > along these lines. > > > > The error should propagate because it indicates a real problem. > > Once we have a proper error and know which os-level operation > > actually failed we should be further. Can you 'svn up', > > reinstall and report about the error/traceback again? > > > Is there a reason why you chose a dynamically created class instead of a > concrete UnknownErrno class? Or would it be useful to have a different > base class for UnknownErrno## classes so that they can be caught > separately? 1) it was the easiest fix 2) it retains the 'errno' in the classname in order to allow catching them specifically (which might make sense if you writing a one-shot script and do want to catch a specific error 3) An UnknownErrno-base class seems like overdoing it since catching such errors would not be very specific, and you can do "except py.error.Error, e: ..." anyway. cheers, holger From hpk at trillke.net Tue Jul 19 19:13:39 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 19 Jul 2005 19:13:39 +0200 Subject: [py-dev] py.test error with cygwin update In-Reply-To: <8b9a72d3050719054421d29ba2@mail.gmail.com> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> <20050719102151.GB18466@solar.trillke.net> <8b9a72d3050719054421d29ba2@mail.gmail.com> Message-ID: <20050719171339.GO18466@solar.trillke.net> Hi, On Tue, Jul 19, 2005 at 08:44 -0400, odonian at gmail.com wrote: > Thanks for the quick help; I did svn up, then setup.py build and > install. A different traceback now appears: > ... > py.error.UnknownErrno136: [No such host or network path]: stat('//conftest.py',) Hum, this looks like a strange path. Can you 'cd' to your testing directory, open a python interactive prompt and issue >>> py.path.local().parts() and send the results here? A different issue is why Python doesn't know about Errno 136 and which error we could map it to. cheers, holger From dstanek at dstanek.com Tue Jul 19 19:33:23 2005 From: dstanek at dstanek.com (David Stanek) Date: Tue, 19 Jul 2005 13:33:23 -0400 (EDT) Subject: [py-dev] py.test error with cygwin update In-Reply-To: <20050719165215.GN18466@solar.trillke.net> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> <20050719102151.GB18466@solar.trillke.net> <32312.207.58.192.150.1121789903.squirrel@207.58.192.150> <20050719165215.GN18466@solar.trillke.net> Message-ID: <38244.207.58.192.150.1121794403.squirrel@207.58.192.150> Hello, > 1) it was the easiest fix > 2) it retains the 'errno' in the classname in order to allow > catching them specifically (which might make sense if you > writing a one-shot script and do want to catch a specific > error > 3) An UnknownErrno-base class seems like overdoing it since catching > such errors would not be very specific, and you can do > "except py.error.Error, e: ..." anyway. > Makes sense. I cannot think of a use-case now, but I thought maybe there would be a reason to catch all UnknownErrno## classes without catching all py.error.Error subclasses. If you do catch all Error classes you would have to evaluate the e.__class__.__name__ to see if it begins with "UnknownErrno". Don't mind me, it's probably just my tendency to overdesign :-) Regards, David From odonian at gmail.com Tue Jul 19 23:18:00 2005 From: odonian at gmail.com (odonian at gmail.com) Date: Tue, 19 Jul 2005 17:18:00 -0400 Subject: [py-dev] py.test error with cygwin update In-Reply-To: <20050719171339.GO18466@solar.trillke.net> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> <20050719102151.GB18466@solar.trillke.net> <8b9a72d3050719054421d29ba2@mail.gmail.com> <20050719171339.GO18466@solar.trillke.net> Message-ID: <8b9a72d3050719141857949c53@mail.gmail.com> Hi holger, OK, the project is under my home directory (called ~/LENS), and tests are under that as ~/LENS/tests. Here's the result of your suggestion: Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import py >>> py.path.local().parts() [local('/'), local('/home'), local('/home/Nonlinear'), local('/home/Nonlinear/LENS')] >>> Looks OK to me, but I'm used to it. :-) Any further ideas? Thanks, S.A. On 7/19/05, holger krekel wrote: > Hi, > > On Tue, Jul 19, 2005 at 08:44 -0400, odonian at gmail.com wrote: > > Thanks for the quick help; I did svn up, then setup.py build and > > install. A different traceback now appears: > > ... > > py.error.UnknownErrno136: [No such host or network path]: stat('//conftest.py',) > > Hum, this looks like a strange path. Can you 'cd' to your testing > directory, open a python interactive prompt and issue > > >>> py.path.local().parts() > > and send the results here? > > A different issue is why Python doesn't know about Errno 136 > and which error we could map it to. > > cheers, > > holger > From hpk at trillke.net Wed Jul 20 22:03:01 2005 From: hpk at trillke.net (holger krekel) Date: Wed, 20 Jul 2005 22:03:01 +0200 Subject: [py-dev] py.test error with cygwin update In-Reply-To: <8b9a72d3050719141857949c53@mail.gmail.com> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> <20050719102151.GB18466@solar.trillke.net> <8b9a72d3050719054421d29ba2@mail.gmail.com> <20050719171339.GO18466@solar.trillke.net> <8b9a72d3050719141857949c53@mail.gmail.com> Message-ID: <20050720200301.GD18466@solar.trillke.net> Hi S.A., On Tue, Jul 19, 2005 at 17:18 -0400, odonian at gmail.com wrote: > OK, the project is under my home directory (called ~/LENS), and tests > are under that as ~/LENS/tests. Here's the result of your suggestion: > > Python 2.4.1 (#1, May 27 2005, 18:02:40) > [GCC 3.3.3 (cygwin special)] on cygwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import py > >>> py.path.local().parts() > [local('/'), local('/home'), local('/home/Nonlinear'), > local('/home/Nonlinear/LENS')] > >>> ok, that looks good so far. > > > Thanks for the quick help; I did svn up, then setup.py build and > > > install. A different traceback now appears: > > > ... > > > py.error.UnknownErrno136: [No such host or network path]: stat('//conftest.py',) OK, the double-slash is a problem which only triggers a real error on windows (on posix systems you can use any number of slashes without problems). i think i have fixed that problem now (rev 14834). can you svn up + retry? cheers, holger From odonian at gmail.com Wed Jul 20 22:19:26 2005 From: odonian at gmail.com (odonian at gmail.com) Date: Wed, 20 Jul 2005 16:19:26 -0400 Subject: [py-dev] py.test error with cygwin update In-Reply-To: <20050720200301.GD18466@solar.trillke.net> References: <8b9a72d3050718213836ad3f83@mail.gmail.com> <20050719102151.GB18466@solar.trillke.net> <8b9a72d3050719054421d29ba2@mail.gmail.com> <20050719171339.GO18466@solar.trillke.net> <8b9a72d3050719141857949c53@mail.gmail.com> <20050720200301.GD18466@solar.trillke.net> Message-ID: <8b9a72d305072013195b5b1ae6@mail.gmail.com> Everything works just fine now with py.test, I am one happy coder. Thank you very much holger! Many future py.test users working on cygwin will also owe thanks for avoided frustration, S.A. On 7/20/05, holger krekel wrote: > Hi S.A., > > On Tue, Jul 19, 2005 at 17:18 -0400, odonian at gmail.com wrote: > > OK, the project is under my home directory (called ~/LENS), and tests > > are under that as ~/LENS/tests. Here's the result of your suggestion: > > > > Python 2.4.1 (#1, May 27 2005, 18:02:40) > > [GCC 3.3.3 (cygwin special)] on cygwin > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import py > > >>> py.path.local().parts() > > [local('/'), local('/home'), local('/home/Nonlinear'), > > local('/home/Nonlinear/LENS')] > > >>> > > ok, that looks good so far. > > > > > Thanks for the quick help; I did svn up, then setup.py build and > > > > install. A different traceback now appears: > > > > ... > > > > py.error.UnknownErrno136: [No such host or network path]: stat('//conftest.py',) > > OK, the double-slash is a problem which only triggers a real error on windows > (on posix systems you can use any number of slashes without problems). > > i think i have fixed that problem now (rev 14834). can you svn up + retry? > > cheers, > > holger > > From ianb at colorstudy.com Wed Jul 27 18:51:39 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 27 Jul 2005 11:51:39 -0500 Subject: [py-dev] py.log -- annotating logs Message-ID: <42E7BB9B.3040702@colorstudy.com> I haven't actually used py.log yet, but was just doing logging in another context, and I'm curious if py.log solves the problem, or if it could be made to do so. Specifically, I want to add contextual information to all my logging. In a web app that might be the remote IP address, session ID, or username. Other environments usually have other context. The actual information would probably live in threadlocal storage. Looking at Grig's blog post, one way would be with a consumer that wraps another consumer. But this seems like it would lead to potentially complex consumer composition, especially since there's a number of things that are possibly being pushed into consumers. Maybe that's not so bad -- I personally am inclined toward that kind of composition anyway. Really py.log could just be thin wrapper around record objects, where everything is dispatched to a single consumer. Like maybe I'd do: def add_remote_ip(old_consumer): def new_consumer(message): message.remote_ip = get_current_remote_ip() message.format = '[%(keywords)s] %(time)s %(remote_ip)s %(message)s' return old_consumer(message) return new_consumer py.log.set_consumer(annotate_consumer(py.log.get_consumer())) message.format looks a little fragile, though. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From ianb at colorstudy.com Wed Jul 27 19:31:15 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 27 Jul 2005 12:31:15 -0500 Subject: [py-dev] py.log -- annotating logs In-Reply-To: <20050727171744.79919.qmail@web54509.mail.yahoo.com> References: <20050727171744.79919.qmail@web54509.mail.yahoo.com> Message-ID: <42E7C4E3.2090609@colorstudy.com> I'm guessing you meant to copy the list... Grig Gheorghiu wrote: > Maybe the easiest way would be to just define a consumer per > "application domain", i.e. for your Web app you'd have a > web_app_consumer() function that would know how to print all the info > you need. > > The way it works right now is that you need to associate a consumer > with one or more keywords. Then you have the flexibility of changing > consumers for those keywords dynamically via configuration files etc. > > So I'd do something like this in a configuration file: > > log = py.log.Producer("mywebapp") > def my_consumer(message): > remote_ip = get_current_remote_ip() > crt_time = get_current_time() > message.args = [crt_time, remote_ip] + message.args > print str(message) # prints "[mywebapp] crt_time remote_ip > " This particular example doesn't work well with other consumers. I'd want to change the message and then let another consumer deal with that message. Unfortunately this kind of composition through dispatching is very configuration-unfriendly -- that's something we're hitting with WSGI middleware configuration right now. But what makes it unfriendly is also what makes it very flexible. The wrapping consumer I gave before could, potentially, be inserted in a number of places. It could be put in place globally, or for a single keyword, or whatever. This presumes, of course, that it's possible to find consumers without running them, so a new consumer can be inserted instead of just overwriting the old one. This can be challenging in itself. There might be one root consumer. Let's say by default it's the consumer that dispatches based on keyword. If we try to insert another consumer in the root consumer, and the dispatching consumer has been replaced, the replacement doesn't necessarily have the same API. Should that replacement consumer send all unknown attributes to its sub-consumer? But the keyword dispatching consumer doesn't have a single sub-consumer to dispatch to, so that doesn't work there. And other dispatchers are also possible -- for instance, this application supports multiple clients, and if a client is associated with a request I'd like to put the log file in a location specific to that client. But that's more programmatic than keywords, and I can create the sub-consumers dynamically. Or maybe some component is generating annoying log messages, and I want to filter them out based on some really arbitrary expression. There's lots of possibilities. But the setup can become hard. But then, it's clear that the logging module doesn't have easy setup either. > py.log.set_consumer("mywebapp", my_consumer) > > Then you would just use log(message) in your code. > > Does this help or maybe I'm way off the mark? -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From grig at gheorghiu.net Wed Jul 27 20:57:54 2005 From: grig at gheorghiu.net (Grig Gheorghiu) Date: Wed, 27 Jul 2005 11:57:54 -0700 (PDT) Subject: [py-dev] py.log -- annotating logs In-Reply-To: <42E7C4E3.2090609@colorstudy.com> Message-ID: <20050727185754.64826.qmail@web54501.mail.yahoo.com> --- Ian Bicking wrote: > I'm guessing you meant to copy the list... > > Grig Gheorghiu wrote: > > Maybe the easiest way would be to just define a consumer per > > "application domain", i.e. for your Web app you'd have a > > web_app_consumer() function that would know how to print all the > info > > you need. > > > > The way it works right now is that you need to associate a consumer > > with one or more keywords. Then you have the flexibility of > changing > > consumers for those keywords dynamically via configuration files > etc. > > > > So I'd do something like this in a configuration file: > > > > log = py.log.Producer("mywebapp") > > def my_consumer(message): > > remote_ip = get_current_remote_ip() > > crt_time = get_current_time() > > message.args = [crt_time, remote_ip] + message.args > > print str(message) # prints "[mywebapp] crt_time remote_ip > > " > > This particular example doesn't work well with other consumers. I'd > want to change the message and then let another consumer deal with > that > message. > > Unfortunately this kind of composition through dispatching is very > configuration-unfriendly -- that's something we're hitting with WSGI > middleware configuration right now. But what makes it unfriendly is > also what makes it very flexible. > > The wrapping consumer I gave before could, potentially, be inserted > in a > number of places. It could be put in place globally, or for a single > > keyword, or whatever. This presumes, of course, that it's possible > to > find consumers without running them, so a new consumer can be > inserted > instead of just overwriting the old one. > > This can be challenging in itself. There might be one root consumer. > > Let's say by default it's the consumer that dispatches based on > keyword. > If we try to insert another consumer in the root consumer, and the > dispatching consumer has been replaced, the replacement doesn't > necessarily have the same API. Should that replacement consumer send > > all unknown attributes to its sub-consumer? But the keyword > dispatching > consumer doesn't have a single sub-consumer to dispatch to, so that > doesn't work there. And other dispatchers are also possible -- for > instance, this application supports multiple clients, and if a client > is > associated with a request I'd like to put the log file in a location > specific to that client. But that's more programmatic than keywords, > > and I can create the sub-consumers dynamically. Or maybe some > component > is generating annoying log messages, and I want to filter them out > based > on some really arbitrary expression. There's lots of possibilities. > But the setup can become hard. > > But then, it's clear that the logging module doesn't have easy setup > either. > You're right, you get tremendous flexibility, but the onus is on you to cleanly configure it. I think this fits well with the overall py lib mantra, which is "No API" :-) Seriously though, I think Holger's intention with py.log is to keep it as simple as possible and let the application developers worry about creating specific consumers, etc. But if you start using it on Paste and add your own hierarchy of consumers, then I'm sure we'll be able to incorporate tons of features back into the py.log basic functionality. Grig From kickdaddy at gmail.com Thu Jul 28 21:51:34 2005 From: kickdaddy at gmail.com (Sean Leach) Date: Thu, 28 Jul 2005 12:51:34 -0700 Subject: [py-dev] Really simple question about py.test Message-ID: <456664705072812511008f4dd@mail.gmail.com> Why does this execute the same test twice (it only happens on a failed test): % cat test_twice.py def fail(): print 'running failed' return False class TestTwice: def test_twice(self): assert fail() % py.test test_twice.py It will print 'running failed' twice (and of course run fail() twice). Is this a feature I am missing in the docs? I really don't want my failed tests to run twice. I am using the latest svn code. Regards, Sean From ianb at colorstudy.com Thu Jul 28 22:03:44 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 28 Jul 2005 15:03:44 -0500 Subject: [py-dev] Really simple question about py.test In-Reply-To: <456664705072812511008f4dd@mail.gmail.com> References: <456664705072812511008f4dd@mail.gmail.com> Message-ID: <42E93A20.7060106@colorstudy.com> Sean Leach wrote: > Why does this execute the same test twice (it only happens on a failed test): > > % cat test_twice.py > def fail(): > print 'running failed' > return False > > class TestTwice: > def test_twice(self): > assert fail() > > % py.test test_twice.py > > It will print 'running failed' twice (and of course run fail() twice). > Is this a feature I am missing in the docs? I really don't want my > failed tests to run twice. py.test reinterprets the expressions in an assert statement (not the entire test), to give you more detail on why it failed (e.g., if you do "assert foo == bar" it'll reinterpret "foo" and "bar" to help you understand why it failed). As a general rule you shouldn't have side effects in your assertions, so you wouldn't really notice it was interpreted twice. If you take the side effect out like: value = fail() assert value Then fail() won't be run twice. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From kickdaddy at gmail.com Thu Jul 28 22:31:14 2005 From: kickdaddy at gmail.com (Sean Leach) Date: Thu, 28 Jul 2005 13:31:14 -0700 Subject: [py-dev] Really simple question about py.test In-Reply-To: <42E93A20.7060106@colorstudy.com> References: <456664705072812511008f4dd@mail.gmail.com> <42E93A20.7060106@colorstudy.com> Message-ID: <4566647050728133124a2ea16@mail.gmail.com> Ahh, very cool, thanks Ian! On 7/28/05, Ian Bicking wrote: > Sean Leach wrote: > > Why does this execute the same test twice (it only happens on a failed test): > > > > % cat test_twice.py > > def fail(): > > print 'running failed' > > return False > > > > class TestTwice: > > def test_twice(self): > > assert fail() > > > > % py.test test_twice.py > > > > It will print 'running failed' twice (and of course run fail() twice). > > Is this a feature I am missing in the docs? I really don't want my > > failed tests to run twice. > > py.test reinterprets the expressions in an assert statement (not the > entire test), to give you more detail on why it failed (e.g., if you do > "assert foo == bar" it'll reinterpret "foo" and "bar" to help you > understand why it failed). > > As a general rule you shouldn't have side effects in your assertions, so > you wouldn't really notice it was interpreted twice. If you take the > side effect out like: > > value = fail() > assert value > > Then fail() won't be run twice. > > -- > Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org > From mscott at goldenspud.com Fri Jul 29 03:47:41 2005 From: mscott at goldenspud.com (Matthew Scott) Date: Thu, 28 Jul 2005 20:47:41 -0500 Subject: [py-dev] Using py.test with PyQt Message-ID: <42E98ABD.9030900@goldenspud.com> I currently have a need to write some unit tests for some custom PyQt widgets, so I put together a base class for py.test based unit tests and a corresponding QApplication subclass. The code is available here if anyone would like to use it: http://svn.orbtech.com/cgi-bin/schevo.cgi/file/branches/rebel/schevo_qt/test/__init__.py Tests that may also serve as additional documentation are available here: http://svn.orbtech.com/cgi-bin/schevo.cgi/file/branches/rebel/schevo_qt/test/test_test.py It's pretty simple right now, but I'll probably take a closer look at something like http://pyguiunit.sourceforge.net/ and implement some helper functions like click(), typeText(), and so forth. Feedback welcome and appreciated... -- Matthew R. Scott From spamtrap at day8.com.au Fri Jul 29 15:33:04 2005 From: spamtrap at day8.com.au (Michael Thompson) Date: Fri, 29 Jul 2005 23:33:04 +1000 Subject: [py-dev] Re: Using py.test with PyQt In-Reply-To: <42E98ABD.9030900@goldenspud.com> References: <42E98ABD.9030900@goldenspud.com> Message-ID: Matthew Scott wrote: > I currently have a need to write some unit tests for some custom PyQt > widgets, so I put together a base class for py.test based unit tests and > a corresponding QApplication subclass. > > The code is available here if anyone would like to use it: > > http://svn.orbtech.com/cgi-bin/schevo.cgi/file/branches/rebel/schevo_qt/test/__init__.py > > Tests that may also serve as additional documentation are available here: > > http://svn.orbtech.com/cgi-bin/schevo.cgi/file/branches/rebel/schevo_qt/test/test_test.py > > > It's pretty simple right now, but I'll probably take a closer look at > something like http://pyguiunit.sourceforge.net/ and implement some > helper functions like click(), typeText(), and so forth. > > > Feedback welcome and appreciated... > > If you want a version of pyQuiUnit amended for py.test, you might be interested in the attached. I've used it a bit (but it is by no means polished code) and found it very useful. -- Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: QtWidgetTester.zip Type: application/x-zip-compressed Size: 7797 bytes Desc: not available URL: From briandorsey at gmail.com Fri Jul 29 23:25:06 2005 From: briandorsey at gmail.com (Brian Dorsey) Date: Fri, 29 Jul 2005 14:25:06 -0700 Subject: [py-dev] Re: [py-svn] r15385 - in py/dist/py: . io io/test test test/terminal test/testing thread/testing In-Reply-To: <20050729211101.69BCB27B5D@code1.codespeak.net> References: <20050729211101.69BCB27B5D@code1.codespeak.net> Message-ID: <66e877b705072914251871d6f7@mail.gmail.com> On 29/07/05, hpk at codespeak.net wrote: > py.test now uses py.io.OutErrCapture to capture > stdout/stderr and should be a bit more robust. > We can easily switch back to the old more shallow > way of stdout/stderr capturing (which just patched > sys.stdout and sys.stderr) should there be a need. > > the py.io-interface is likely to get refined > a bit over time so use with some care. > > i am interested to hear especially if there > are problems on win32 regarding running py.test. It seems to work for me. All I did was verify that my tests still run, and that when I introduce a failure, I still see output from 'print', but that much at least works. Take care, -Brian From hpk at trillke.net Sat Jul 30 11:08:03 2005 From: hpk at trillke.net (holger krekel) Date: Sat, 30 Jul 2005 11:08:03 +0200 Subject: [py-dev] tkinter tests failing after capture changes Message-ID: <20050730090803.GY3501@solar.trillke.net> Hi Jan, it appears that at least on my linux machine two tkinter related tests are failing after the recent IO-capturing changes (we are now doing capturing on FD-level as well as on sys.stdout/stderr level). I couldn't figure out so far what the actual problem is. Can you have a look? The two failing tests are (i guess you will get them as well): py/test/tkinter/testing/test_capture_out_err.py:16 py/test/tkinter/testing/test_backend.py:188 cheers & thanks, holger From jan at balster.info Sun Jul 31 01:49:03 2005 From: jan at balster.info (Jan Balster) Date: Sun, 31 Jul 2005 01:49:03 +0200 Subject: [py-dev] Re: tkinter tests failing after capture changes In-Reply-To: <20050730090803.GY3501@solar.trillke.net> References: <20050730090803.GY3501@solar.trillke.net> Message-ID: <42EC11EF.1070307@balster.info> holger krekel wrote: > Hi Jan, > > it appears that at least on my linux machine two tkinter > related tests are failing after the recent IO-capturing > changes (we are now doing capturing on FD-level as well as on > sys.stdout/stderr level). I couldn't figure out so far what > the actual problem is. Can you have a look? > > The two failing tests are (i guess you will > get them as well): > > py/test/tkinter/testing/test_capture_out_err.py:16 > py/test/tkinter/testing/test_backend.py:188 > > cheers & thanks, > > holger > Hi Holger, yes, i get the two failing tests. I think the new IO-capturing doesn't work with py.execnet.gateway. If i run the tests with the --looponfailing option i get this captured output: - - - - - - - - - test_capture_out_err.py: recorded stdout - - - - - - - - - - !'testing/test_capture_out_err.py''[1] ''\n' - - - - - - - - - - test_capture_out_err: recorded stdout - - - - - - - - - - 'F' _______________________________________________________________________________ ============= tests finished: 63 passed, 2 failed in 9.63 seconds ============= It looks like "channel data". Do you get the same output? Jan PS: Here is a little failing testcase: "channel.send() doesn't work while capturing stdout and stderr" Testcase: import py def test_channel_send_and_capture(): gateway = py.execnet.PopenGateway() channel = gateway.newchannel() gateway.remote_exec(channel = channel, source = ''' import py cap = py.io.OutErrCapture() channel.send('sending works') cap.reset() ''') data = channel.receive() assert data == 'sending works' channel.waitclose(1) channel.gateway.exit() Testoutput: _____________________________________________________________________________ _______ entrypoint: test_channel_send_and_capture__________ _________________ def test_channel_send_and_capture(): gateway = py.execnet.PopenGateway() channel = gateway.newchannel() gateway.remote_exec(channel = channel, source = ''' import py cap = py.io.OutErrCapture() channel.send('sending works') cap.reset() ''') > data = channel.receive() [.../py/io/test/test_capture.py:150] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ def receive(self): """receives an item that was sent from the other side, possibly blocking if there is none. Note that exceptions from the other side will be reraised as channel.RemoteError exceptions containing a textual representation of the remote traceback. """ if self._receiver: raise IOError("calling receive() on channel with receiver callback") x = self._items.get() if x is ENDMARKER: self._items.put(x) # for other receivers E raise self._stickyerror > EOFError [.../py/execnet/channel.py:126] From hpk at trillke.net Sun Jul 31 08:35:37 2005 From: hpk at trillke.net (holger krekel) Date: Sun, 31 Jul 2005 08:35:37 +0200 Subject: [py-dev] Re: tkinter tests failing after capture changes In-Reply-To: <42EC11EF.1070307@balster.info> References: <20050730090803.GY3501@solar.trillke.net> <42EC11EF.1070307@balster.info> Message-ID: <20050731063537.GD3501@solar.trillke.net> Hi Jan, On Sun, Jul 31, 2005 at 01:49 +0200, Jan Balster wrote: > holger krekel wrote: > > it appears that at least on my linux machine two tkinter > > related tests are failing after the recent IO-capturing > > changes (we are now doing capturing on FD-level as well as on > > sys.stdout/stderr level). I couldn't figure out so far what > > the actual problem is. Can you have a look? > > > > The two failing tests are (i guess you will > > get them as well): > > > > py/test/tkinter/testing/test_capture_out_err.py:16 > > py/test/tkinter/testing/test_backend.py:188 > > > > cheers & thanks, > > > > holger > > > > Hi Holger, > > yes, i get the two failing tests. I think the new IO-capturing doesn't work with > py.execnet.gateway. i think you are right and i/we'll need to investigate further. py.execnet has some serious refactorings awaiting anyway which I discussed with Armin around the ongoing PyPy sprint. Maybe it makes sense to switch back to the more shallow capturing meanwhile ... thanks & cheers, holger