From faassen at startifact.com Tue Dec 11 19:56:13 2007 From: faassen at startifact.com (Martijn Faassen) Date: Tue, 11 Dec 2007 19:56:13 +0100 Subject: [py-dev] username and password support for py.path.svnwc Message-ID: Hi there, Looking at the API and grepping around the source it seems there is no obvious support for username/password in py.path.svnwc. I'd like to be able to do a checkout as a particular user, and give a password programmatically. Is there any way I'm not seeing, or is this indeed a missing feature? I could spend a bit of time adding this, but I do need to have some idea of when a release will happen. Regards, Martijn From fijal at genesilico.pl Wed Dec 12 11:27:36 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Wed, 12 Dec 2007 11:27:36 +0100 Subject: [py-dev] username and password support for py.path.svnwc In-Reply-To: References: Message-ID: <475FB798.9010509@genesilico.pl> Martijn Faassen wrote: > Hi there, > > Looking at the API and grepping around the source it seems there is no > obvious support for username/password in py.path.svnwc. I'd like to be > able to do a checkout as a particular user, and give a password > programmatically. > > Is there any way I'm not seeing, or is this indeed a missing feature? > > I could spend a bit of time adding this, but I do need to have some idea > of when a release will happen. > > Regards, > > Martijn > Hum. I hoped that 0.9.1 will happen at the sprint, but for various reasons it didn't. I hope we'll not miss holiday season with that :) If changes would be large, I hope to release it together with 1.0 before pycon 2008 (March) in order to have 1.0 ready for a talk (a bit of marketing). Cheers, fijal :. From johnny at johnnydebris.net Wed Dec 12 12:26:26 2007 From: johnny at johnnydebris.net (Guido Wesdorp) Date: Wed, 12 Dec 2007 12:26:26 +0100 Subject: [py-dev] username and password support for py.path.svnwc In-Reply-To: References: Message-ID: <475FC562.5050308@johnnydebris.net> Martijn Faassen wrote: > I could spend a bit of time adding this, but I do need to have some idea > of when a release will happen. > > If you start working on this, perhaps we can use screen and pair? (Also we still need to go for a beer, perhaps we can combine? Are you back from your mother's already, and do you have time this week perhaps?) Cheers, Guido From jgv-home at comcast.net Sat Dec 15 13:26:04 2007 From: jgv-home at comcast.net (j. vickroy) Date: Sat, 15 Dec 2007 05:26:04 -0700 Subject: [py-dev] py.test generative tests unexpected behavior Message-ID: <4763C7DC.7080900@comcast.net> Hello all, I'm a first time user of py.tests. My setup is: * py.test v0.9.0 * Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 * Microsoft Windows XP Pro (service pack 2) The attached file (py-test-generator-trial.py) demonstrates a behavior I do not understand. When test_filters() is implemented as a generator, the tests appear to be run twice and all tests fail during the second iteration except for the final case ('AL12_1','Gray') in the loop. When the yield statement, in test_filters(), is disabled and the assertion statement is enabled, the behavior is as expected -- namely the tests are performed once and all pass. Could someone help me to understand this behavior? Thanks, --jv P.S. I could provide captured output if that is helpful. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: py-test-generator-trial.py URL: From Jim.Vickroy at noaa.gov Mon Dec 17 15:45:28 2007 From: Jim.Vickroy at noaa.gov (Jim.Vickroy at noaa.gov) Date: Mon, 17 Dec 2007 07:45:28 -0700 Subject: [py-dev] Fwd: [Fwd: Re: py.test generative tests behavior unexpected] Message-ID: An embedded message was scrubbed... From: Jim Vickroy Subject: [Fwd: Re: py.test generative tests behavior unexpected] Date: Fri, 14 Dec 2007 22:36:10 +0000 Size: 4149 URL: From cfbolz at gmx.de Mon Dec 17 16:25:36 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 17 Dec 2007 16:25:36 +0100 Subject: [py-dev] py.test generative tests unexpected behavior In-Reply-To: <4763C7DC.7080900@comcast.net> References: <4763C7DC.7080900@comcast.net> Message-ID: <476694F0.8080107@gmx.de> Hi! j. vickroy wrote: [snip] > The attached file (py-test-generator-trial.py) demonstrates a behavior I > do not understand. [snip] I don't know generative test semantics all that well, I hoped somebody else would answer this. However, my theory is as follows: py.test first collects all the results of the generator and then runs them all. Since your test keeps global state, the state is already changed when the first test is run. To me this sounds like reasonable behavior, global state is not good in tests anyway. Does that make things clearer? Cheers, Carl Friedrich From Jim.Vickroy at noaa.gov Mon Dec 17 17:45:04 2007 From: Jim.Vickroy at noaa.gov (Jim.Vickroy at noaa.gov) Date: Mon, 17 Dec 2007 09:45:04 -0700 Subject: [py-dev] py.test generative tests unexpected behavior Message-ID: ----- Original Message ----- From: Carl Friedrich Bolz Date: Monday, December 17, 2007 8:25 am Subject: Re: [py-dev] py.test generative tests unexpected behavior > Hi! > > j. vickroy wrote: > [snip] > > The attached file (py-test-generator-trial.py) demonstrates a > behavior I > > do not understand. > [snip] > > I don't know generative test semantics all that well, I hoped > somebody > else would answer this. However, my theory is as follows: > > py.test first collects all the results of the generator and then > runs > them all. Since your test keeps global state, the state is already > changed when the first test is run. To me this sounds like > reasonable > behavior, global state is not good in tests anyway. > > Does that make things clearer? > > Cheers, > > Carl Friedrich > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > Thanks, Carl. I do understand (at least) some of the pitfalls of global state and I do *almost always* avoid using it. However, in this case, I am having difficulty seeing why it is responsible for the observed behavior. Having said that, prior to using the global *image* object, I tried to use the setup_module(module) function to define the *image* object but was unable to determine how to reference it in the test function. The global *image* object was a crude work-around. Can you offer some suggestions on how I should have proceeded given that I really do not need to create a new *image* object for each test. Thanks again, -- jv From cfbolz at gmx.de Mon Dec 17 18:07:21 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 17 Dec 2007 18:07:21 +0100 Subject: [py-dev] py.test generative tests unexpected behavior In-Reply-To: References: Message-ID: <4766ACC9.4090707@gmx.de> Jim.Vickroy at noaa.gov wrote: > > ----- Original Message ----- > From: Carl Friedrich Bolz > Date: Monday, December 17, 2007 8:25 am > Subject: Re: [py-dev] py.test generative tests unexpected behavior > >> Hi! >> >> j. vickroy wrote: >> [snip] >>> The attached file (py-test-generator-trial.py) demonstrates a >> behavior I >>> do not understand. >> [snip] >> >> I don't know generative test semantics all that well, I hoped >> somebody >> else would answer this. However, my theory is as follows: >> >> py.test first collects all the results of the generator and then >> runs >> them all. Since your test keeps global state, the state is already >> changed when the first test is run. To me this sounds like >> reasonable >> behavior, global state is not good in tests anyway. >> >> Does that make things clearer? >> >> Cheers, >> >> Carl Friedrich >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev >> > > Thanks, Carl. > > I do understand (at least) some of the pitfalls of global state and I do > *almost always* avoid using it. However, in this case, I am having > difficulty seeing why it is responsible for the observed behavior. I think what py.test does is essentially this: l = list(test_filters()) # at this point source.info['palette'] == 'Gray' # and that won't change any more for t in l: t[0](*t[1:]) # here the check functions are executed > Having said that, prior to using the global *image* object, I tried to > use the setup_module(module) function to define the *image* object but > was unable to determine how to reference it in the test function. You can stick the the image into the module argument that the setup_module function receives as first arg: def setup_module(mod): mod.image = ... After the setup, the global name 'image' is bound to ... This wouldn't have solved your problem, though, since it is still global state. [snip] Cheers, Carl Friedrich From Jim.Vickroy at noaa.gov Mon Dec 17 19:10:11 2007 From: Jim.Vickroy at noaa.gov (Jim.Vickroy at noaa.gov) Date: Mon, 17 Dec 2007 11:10:11 -0700 Subject: [py-dev] py.test generative tests unexpected behavior Message-ID: ----- Original Message ----- From: Carl Friedrich Bolz Date: Monday, December 17, 2007 10:07 am Subject: Re: [py-dev] py.test generative tests unexpected behavior > Jim.Vickroy at noaa.gov wrote: > > > > ----- Original Message ----- > > From: Carl Friedrich Bolz > > Date: Monday, December 17, 2007 8:25 am > > Subject: Re: [py-dev] py.test generative tests unexpected behavior > > > >> Hi! > >> > >> j. vickroy wrote: > >> [snip] > >>> The attached file (py-test-generator-trial.py) demonstrates a > >> behavior I > >>> do not understand. > >> [snip] > >> > >> I don't know generative test semantics all that well, I hoped > >> somebody > >> else would answer this. However, my theory is as follows: > >> > >> py.test first collects all the results of the generator and then > >> runs > >> them all. Since your test keeps global state, the state is > already > >> changed when the first test is run. To me this sounds like > >> reasonable > >> behavior, global state is not good in tests anyway. > >> > >> Does that make things clearer? > >> > >> Cheers, > >> > >> Carl Friedrich > >> _______________________________________________ > >> py-dev mailing list > >> py-dev at codespeak.net > >> http://codespeak.net/mailman/listinfo/py-dev > >> > > > > Thanks, Carl. > > > > I do understand (at least) some of the pitfalls of global state > and I do > > *almost always* avoid using it. However, in this case, I am having > > difficulty seeing why it is responsible for the observed behavior. > > I think what py.test does is essentially this: > > l = list(test_filters()) > # at this point source.info['palette'] == 'Gray' > # and that won't change any more > for t in l: > t[0](*t[1:]) # here the check functions are executed > > > > Having said that, prior to using the global *image* object, I > tried to > > use the setup_module(module) function to define the *image* > object but > > was unable to determine how to reference it in the test function. > > You can stick the the image into the module argument that the > setup_module function receives as first arg: > > def setup_module(mod): > mod.image = ... > > After the setup, the global name 'image' is bound to ... > This wouldn't have solved your problem, though, since it is still > global > state. > > [snip] > > Cheers, > > Carl Friedrich OK, it seems that module-level objects are not really suitable for use in the generative framework. Diagnostic statements show each test is actually being run twice and that the second running is where the failures occur. A work-around, in this particular situation, is to create a new test object for each iteration of the generator and that is not too expensive here, but I do have concerns about scalability of this approach. Thanks again for your follow-ups. --jv > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev >