Re: [Python-Dev] PEP 385 progress report
On Wed, Feb 10, 2010 at 02:03, Benjamin Peterson wrote: > What do you mean by moved? I don't it has ever moved around in the sandbox. IIRC it was moved into the sandbox from some other location at some point? Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues
On 10/02/2010 01:07, Ben Finney wrote: Michael Foord writes: On 09/02/2010 21:50, Ben Finney wrote: I understood the point of ‘TestCase.shortDescription’, and indeed the point of that particular name, was to be clear that some *other* text could be the short description for the test case. Indeed, this is what you've come up with: a different implementation for generating a short description. Given that the change broke something, and the desired effect can be gained with a different change, I don't really see a downside to the change I'm proposing (reverting shortDescription and moving the code that adds the test name to TestResult). What you describe (adding the class and method name when reporting the test) sounds like it belongs in the TestRunner, since it's more a case of “give me more information about the test result”. The code for giving information about individual test results is the TestResult. The TestRunner knows nothing about each individual result (or even about each individual test as it happens). The TestRunner is responsible for the whole test run, the TestCase runs individual tests and the TestResult reports (or holds) individual test results (at the behest of the TestCase). Given this structure it is not possible for test descriptions to be the responsibility of the TestRunner and I don't feel like re-structuring unittest today. :-) Michael That is, a TestRunner that reports each result *with* the extra information would be useful, for some cases, but should not modify the TestResult instance to do that. Am I right that this approach would avoid breakage in the case of frameworks that don't expect their TestRunner to behave that way? e.g. Twisted could simply use the TestRunner that doesn't behave this way, and (since the TestResult instances aren't any different) continue to get the expected behaviour. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.5
On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou wrote: > > Besides, as Barry said, classifying a bug as blocker is also a good way > to attract some attention on it. Other classifications, even "critical", > don't have the same effect. Unfortunately, not many people have privilege to change bug properties to attract attention to the issues. For example, this patch - http://bugs.python.org/issue7582 is ready to be committed, it is trivial, not a release blocker, but would be nice be released. How to make it evident if nobody except committers is able to add any keywords to the issue? I suspect that even committers do not receive this privilege automatically. -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.5
anatoly techtonik gmail.com> writes: > > Unfortunately, not many people have privilege to change bug properties > to attract attention to the issues. For example, this patch - > http://bugs.python.org/issue7582 is ready to be committed, it is > trivial, not a release blocker, but would be nice be released. Well not every bug deserves special attention. The patch above is IMO low priority, since it's a minor addition to a script in the Tools directory... Not something which will make a big difference, and I'm being kind. :) As for setting keywords, there doesn't seem to be much you could have an authority to decide as a non-committer. You might think (and perhaps with good reason) that the patch is ready for commit into the SVN, but it's precisely a committer's job to decide that. (if you want to apply for commit rights, you can do so on this mailing-list; I cannot say if it could be accepted or not, since I haven't followed your contributions very closely. But given you don't even seem to be mentioned in the ACKS file the answer would probably be no at this point) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 385 progress report
2010/2/10 Dirkjan Ochtman : > On Wed, Feb 10, 2010 at 02:03, Benjamin Peterson wrote: >> What do you mean by moved? I don't it has ever moved around in the sandbox. > > IIRC it was moved into the sandbox from some other location at some point? r52858 | guido.van.rossum | 2006-11-29 11:38:40 -0600 (Wed, 29 Nov 2006) | 4 lines Changed paths: A /sandbox/trunk/2to3 A /sandbox/trunk/2to3/Grammar.pickle A /sandbox/trunk/2to3/Grammar.txt A /sandbox/trunk/2to3/pgen2 A /sandbox/trunk/2to3/pgen2/__init__.py A /sandbox/trunk/2to3/pgen2/__init__.pyc A /sandbox/trunk/2to3/pgen2/astnode.py A /sandbox/trunk/2to3/pgen2/conv.py A /sandbox/trunk/2to3/pgen2/driver.py A /sandbox/trunk/2to3/pgen2/grammar.py A /sandbox/trunk/2to3/pgen2/literals.py A /sandbox/trunk/2to3/pgen2/parse.py A /sandbox/trunk/2to3/pgen2/pgen.py A /sandbox/trunk/2to3/pgen2/python.py A /sandbox/trunk/2to3/pgen2/test.py A /sandbox/trunk/2to3/play.py A /sandbox/trunk/2to3/pynode.py Checkpoint of alternative Python 2.x-to-3.0 conversion tool. This contains a modified copy of pgen2 which was open-sourced by Elemental Security through a contributor's agreement with the PSF. The only moving was moving a lot of the files into a lib2to3 directory. It would be nice if the hg history could be preserved for those files. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.5
Antoine Pitrou writes: > Besides, as Barry said, classifying a bug as blocker is also a good way > to attract some attention on it. Other classifications, even "critical", > don't have the same effect. If done for the sole purpose of attracting attention, it's no different from spam. Opinions will differ about what is and is not a blocker, and I'm sure your sense is as conservative as the next guy's. But really, let's at least be in the grey zone; "attracting attention" is not a consideration. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.5
anatoly techtonik writes: > Is it possible to make exploits out of crashers? Depends on how you define "exploit". If your definition includes denial of service, yes, crashing a server application would count. Privilege escalation is harder to achieve. The general answer is "yes", but each case is different, and requires expert analysis. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.5
On Feb 10, 2010, at 01:57 PM, anatoly techtonik wrote: >Unfortunately, not many people have privilege to change bug properties >to attract attention to the issues. For example, this patch - >http://bugs.python.org/issue7582 is ready to be committed, it is >trivial, not a release blocker, but would be nice be released. How to >make it evident if nobody except committers is able to add any >keywords to the issue? I suspect that even committers do not receive >this privilege automatically. You do exactly what you've done here: email python-dev and plead your case. This particular issue seems like a new feature so it's not appropriate for Python 2.6.5. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setUpClass and setUpModule in unittest
On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel wrote: > On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney > wrote: >> Michael Foord writes: >> >>> The next 'big' change to unittest will (may?) be the introduction of >>> class and module level setUp and tearDown. This was discussed on >>> Python-ideas and Guido supported them. They can be useful but are also >>> very easy to abuse (too much shared state, monolithic test classes and >>> modules). Several authors of other Python testing frameworks spoke up >>> *against* them, but several *users* of test frameworks spoke up in >>> favour of them. ;-) >> >> I think the perceived need for these is from people trying to use the >> ‘unittest’ API for test that are *not* unit tests. >> Well the example I was talking about before is when some (critical) resource needed for unittesting requires a very, very heavy initialization process. I'll employ the most recent example (hope it doesn't look like too much biased, it's just to illustrate the whole picture ;o) which is unittests for a framework like Trac . In that case it is critical to have a Trac environment, a ready-to-use DB and backend, initialize the plugins cache by loading relevant plugins, run the actions specified by each IEnvironmentSetup participant, sometimes a ready to use repository (if testing code depending on Trac VCS API) and more ... Just considering these cases someone could : - Create a fake environment used as a stub - But having a single global environment is not a good idea because it would be very difficult to run multiple (independent) tests concurrently (e.g. test multiple Trac plugins concurrently in a dedicated CI environment). So an environment has to be started for every test run and be as isolated as possible from other similar stub environments - The DB and backend can be replaced by using in-memory SQLite connection - Plugins cache and loading is mandatory as well running the actions specified by each IEnvironmentSetup participant - VCS can be mocked, but if it's needed it has to be initialized as well And all this is needed to run *ANY* test of *ANY* kind (that includes unittests ;o) . I hope that, up to this point, you all are convinced of the fact that all this cannot be done for each TestCase instance. That's why something like class-level setup | teardown might be useful to get all this done just once ... but it's not enough Something I consider a limitation of that approach is that it is a little hard to control the scope of setup and teardown. For instance, if I was trying to run Trac test suite I'd like to create the environment stub just once, and not once for every (module | class) containing tests. The current approach does not fit very well scenarios like this (i.e. setup | teardown actions span even beyond single modules ;o) So that's why it seems that the approach included in Trac testing code (i.e. a global shared fixture ) will still be needed, but AFAICR it breaks a little the interface of TC class and setup and tear down has to be performed from the outside. OTOH another minimalistic framework I've been building on top of `dutest` to cope with such scenarios (aka TracDuTest but not oficially released yet :-/ ) seems to handle all those features well enough by using doctest extraglobs or by modifying the global namespace at any given time inside setUp and tearDown (thus hiding all this code from doctests ;o). > One nice bit is that you can for a given test module issue "py.test > --funcargs" > and get a list of resources you can use in your test function - by simply > specifying them in the test function. > > In principle it's possible to port this approach to the stdlib - actually i > consider to do it for the std-unittest- running part of py.test because > people asked for it - if that proves useful i can imagine to refine it > and offer it for inclusion. > Considering part of what I've mentioned above: Q: - How could py.test help in cases like this ? - Considering the similitudes with unittest style (at least IMO) I think I'd prefer something like PeckCheck to generate and run parameterized TCs. What d'u think ? (I confess that I don't use py.test , nose ... because I see they use too much magic & ..., but that's just my *VERY* biased opinion, so I won't start a war or alike ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Nabble - Trac Users - Embedding pages? - http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages--td27358804.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setUpClass and setUpModule in unittest
On Tue, Feb 9, 2010 at 6:15 PM, wrote: > On 10:42 pm, [email protected] wrote: >> >> On 09/02/2010 21:57, Ben Finney wrote: >>> >>> Michael Foord writes: The next 'big' change to unittest will (may?) be the introduction of class and module level setUp and tearDown. This was discussed on Python-ideas and Guido supported them. They can be useful but are also very easy to abuse (too much shared state, monolithic test classes and modules). Several authors of other Python testing frameworks spoke up *against* them, but several *users* of test frameworks spoke up in favour of them. ;-) >>> >>> I think the perceived need for these is from people trying to use the >>> 18unittest 19 API for test that are *not* unit tests. >>> >>> That is, people have a need for integration tests (test this module's >>> interaction with some other module) or system tests (test the behaviour >>> of the whole running system). They then try to crowbar those tests into >>> 18unittest 19 and finding it lacking, since 18unittest 19 is designed >>> for >>> tests of function-level units, without persistent state between those >>> test cases. >> >> I've used unittest for long running functional and integration tests (in >> both desktop and web applications). The infrastructure it provides is great >> for this. Don't get hung up on the fact that it is called unittest. In fact >> for many users the biggest reason it isn't suitable for tests like these is >> the lack of shared fixture support - which is why the other Python test >> frameworks provide them and we are going to bring it into unittest. > > For what it's worth, we just finished *removing* support for setUpClass and > tearDownClass from Trial. > Ok ... but why ? Are they considered dangerous for modern societies ? -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: PEP 391 - Please Vote! - http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setUpClass and setUpModule in unittest
On Tue, Feb 9, 2010 at 8:10 PM, Ben Finney wrote: > Michael Foord writes: > >> I've used unittest for long running functional and integration tests >> (in both desktop and web applications). The infrastructure it provides >> is great for this. Don't get hung up on the fact that it is called >> unittest. In fact for many users the biggest reason it isn't suitable >> for tests like these is the lack of shared fixture support - which is >> why the other Python test frameworks provide them and we are going to >> bring it into unittest. > > I would argue that one of the things that makes ‘unittest’ good is that > it makes it difficult to do the wrong thing — or at least *this* wrong > thing. Fixtures persist for the lifetime of a single test case, and no > more; that's the way unit tests should work. > > Making the distinction clearer by using a different API (and *not* > extending the ‘unittest’ API) seems to be the right way to go. > If that means that development should be focused on including mechanisms to make unittest more extensible instead of complicating the current «relatively simple» API , then I agree . I think about unittest as a framework for writing test cases; but OTOH as a meta-framework to be used as the basic building blocks to build or integrate third-party testing infrastructures (and that includes third-party packages ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Free milestone ranch Download - mac software - http://feedproxy.google.com/~r/TracGViz-full/~3/rX6_RmRWThE/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest: shortDescription, _TextTestResult and other issues
On Wed, Feb 10, 2010 at 6:11 AM, Michael Foord wrote: > On 10/02/2010 01:07, Ben Finney wrote: >> Michael Foord writes: >>> On 09/02/2010 21:50, Ben Finney wrote: I understood the point of ‘TestCase.shortDescription’, and indeed the point of that particular name, was to be clear that some *other* text could be the short description for the test case. Indeed, this is what you've come up with: a different implementation for generating a short description. >>> >>> Given that the change broke something, and the desired effect can be >>> gained with a different change, I don't really see a downside to the >>> change I'm proposing (reverting shortDescription and moving the code >>> that adds the test name to TestResult). >>> >> >> What you describe (adding the class and method name when reporting >> the test) sounds like it belongs in the TestRunner, since it's more a >> case of “give me more information about the test result”. > > The code for giving information about individual test results is the > TestResult. The TestRunner knows nothing about each individual result (or > even about each individual test as it happens). The TestRunner is > responsible for the whole test run, the TestCase runs individual tests and > the TestResult reports (or holds) individual test results (at the behest of > the TestCase). > > Given this structure it is not possible for test descriptions to be the > responsibility of the TestRunner and I don't feel like re-structuring > unittest today. :-) > FWIW +1 -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Nabble - Trac Users - Embedding pages? - http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages--td27358804.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 385 progress report
On Wed, Feb 10, 2010 at 13:59, Benjamin Peterson wrote: > The only moving was moving a lot of the files into a lib2to3 > directory. It would be nice if the hg history could be preserved for > those files. Please see if hg.python.org/2to3 would satisfy your needs. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
On Tue, Feb 9, 2010 at 14:47, Collin Winter wrote: > To follow up on some of the open issues: > > On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter > wrote: > [snip] >> Open Issues >> === >> >> - *Code review policy for the ``py3k-jit`` branch.* How does the CPython >> community want us to procede with respect to checkins on the ``py3k-jit`` >> branch? Pre-commit reviews? Post-commit reviews? >> >> Unladen Swallow has enforced pre-commit reviews in our trunk, but we realize >> this may lead to long review/checkin cycles in a purely-volunteer >> organization. We would like a non-Google-affiliated member of the CPython >> development team to review our work for correctness and compatibility, but >> we >> realize this may not be possible for every commit. > > The feedback we've gotten so far is that at most, only larger, more > critical commits should be sent for review, while most commits can > just go into the branch. Is that broadly agreeable to python-dev? > >> - *How to link LLVM.* Should we change LLVM to better support shared linking, >> and then use shared linking to link the parts of it we need into CPython? > > The consensus has been that we should link shared against LLVM. > Jeffrey Yasskin is now working on this in upstream LLVM. We are > tracking this at > http://code.google.com/p/unladen-swallow/issues/detail?id=130 and > http://llvm.org/PR3201. > >> - *Prioritization of remaining issues.* We would like input from the CPython >> development team on how to prioritize the remaining issues in the Unladen >> Swallow codebase. Some issues like memory usage are obviously critical >> before >> merger with ``py3k``, but others may fall into a "nice to have" category >> that >> could be kept for resolution into a future CPython 3.x release. > > The big-ticket items here are what we expected: reducing memory usage > and startup time. We also need to improve profiling options, both for > oProfile and cProfile. > >> - *Create a C++ style guide.* Should PEP 7 be extended to include C++, or >> should a separate C++ style PEP be created? Unladen Swallow maintains its >> own >> style guide [#us-styleguide]_, which may serve as a starting point; the >> Unladen Swallow style guide is based on both LLVM's [#llvm-styleguide]_ and >> Google's [#google-styleguide]_ C++ style guides. > > Any thoughts on a CPython C++ style guide? My personal preference > would be to extend PEP 7 to cover C++ by taking elements from > http://code.google.com/p/unladen-swallow/wiki/StyleGuide and the LLVM > and Google style guides (which is how we've been developing Unladen > Swallow). If that's broadly agreeable, Jeffrey and I will work on a > patch to PEP 7. > I have found the Google C++ style guide good so I am fine with taking ideas from that and adding them to PEP 7. -Brett > Thanks, > Collin Winter > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.5
On Tue, Feb 9, 2010 at 21:24, Barry Warsaw wrote: > On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote: > >>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit : I've noticed a couple of issues that 100% crash Python 2.6.4 like this one - http://bugs.python.org/issue6608 Is it ok to release new versions that are known to crash? >>> >>> I've changed this issue to release blocker. What are the other issues? >> >> For a bug fix release, it should (IMO) be a release blocker *only* if >> this is a regression in the branch or some recent bug fix release over >> some earlier bug fix release. >> >> E.g. if 2.6.2 had broken something that worked in 2.6.1, it would be ok >> to delay 2.6.5. If 2.6.2 breaks in a case where all prior releases also >> broke, it would NOT be ok, IMO, to block 2.6.5 for that. There can >> always be a 2.6.6 release. >> >> Of course, if this gets fixed before the scheduled release of 2.6.5, >> anyway, that would be nice. > > I completely agree. > Ditto from me. -Brett > Besides, unless we have volunteers to step up, create, review, and apply > patches, it makes no sense to hold up releases. In the case of the first > posted bug, we need a Windows core developer to test, bless and apply the > patch. > > -Barry > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setUpClass and setUpModule in unittest
On Wed, 10 Feb 2010 09:45:41 -0500, Olemis Lang wrote: > On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel wrote: > > On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney > > wrote: > >> Michael Foord writes: > >> > >>> The next 'big' change to unittest will (may?) be the introduction of > >>> class and module level setUp and tearDown. This was discussed on > >>> Python-ideas and Guido supported them. They can be useful but are also > >>> very easy to abuse (too much shared state, monolithic test classes and > >>> modules). Several authors of other Python testing frameworks spoke up > >>> *against* them, but several *users* of test frameworks spoke up in > >>> favour of them. ;-) > >> > >> I think the perceived need for these is from people trying to use the > >> unittest API for test that are *not* unit tests. > >> > > Well the example I was talking about before is when some (critical) > resource needed for unittesting requires a very, very heavy > initialization process. I'll employ the most recent example (hope it > doesn't look like too much biased, it's just to illustrate the whole > picture ;o) which is unittests for a framework like Trac . In that > case it is critical to have a Trac environment, a ready-to-use DB and > backend, initialize the plugins cache by loading relevant plugins, run > the actions specified by each IEnvironmentSetup participant, sometimes > a ready to use repository (if testing code depending on Trac VCS API) > and more ... Just considering these cases someone could : > > - Create a fake environment used as a stub > - But having a single global environment is not a good idea because > it would be very difficult to run multiple (independent) tests > concurrently (e.g. test multiple Trac plugins concurrently in a dedica= > ted > CI environment). So an environment has to be started for every > test run and be as isolated as possible from other similar > stub environments > - The DB and backend can be replaced by using in-memory SQLite > connection > - Plugins cache and loading is mandatory as well running the actions > specified by each IEnvironmentSetup participant > - VCS can be mocked, but if it's needed it has to be initialized as well > > And all this is needed to run *ANY* test of *ANY* kind (that includes > unittests ;o) . I hope that, up to this point, you all are convinced This doesn't sound very unit-testy, really. It sounds like you are operating at a rather high level (closer to integration testing). As someone else said, I don't see anything wrong with using unittest as a basis for doing that myself, but I don't think your example is a clear example of wanting a setup and teardown that is executed once per TestCase for tests that are more obviously what everyone would consider "unit" tests. I do have an example of that, though. I have an external database containing test data. My unittests are generated on the fly so that each generated test method pulls one set of test data from the database and runs the appropriate checks that the package processes the data correctly. (If you are curious, I'm testing email header parsing, and there are a lot of different possible quirky headers that the parser needs to be checked against) Putting the test data in a database makes managing the test data easier, and makes it available to other test frameworks to reuse the data. So, having the connection to the database set up once at TestCase start, and closed at TestCase end, would make the most sense. Currently there's no way I know of to do that, so I open and close the database for every unittest. Fortunately it's an sqlite database, so the run time penalty for doing that isn't prohibitive. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setUpClass and setUpModule in unittest
On Wed, Feb 10, 2010 at 3:56 PM, R. David Murray wrote: > On Wed, 10 Feb 2010 09:45:41 -0500, Olemis Lang wrote: >> On Tue, Feb 9, 2010 at 5:34 PM, Holger Krekel >> wrote: >> > On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney >> > wrote: >> >> Michael Foord writes: >> >> >> >>> The next 'big' change to unittest will (may?) be the introduction of >> >>> class and module level setUp and tearDown. This was discussed on >> >>> Python-ideas and Guido supported them. They can be useful but are also >> >>> very easy to abuse (too much shared state, monolithic test classes and >> >>> modules). Several authors of other Python testing frameworks spoke up >> >>> *against* them, but several *users* of test frameworks spoke up in >> >>> favour of them. ;-) >> >> >> >> I think the perceived need for these is from people trying to use the >> >> unittest API for test that are *not* unit tests. >> >> >> >> Well the example I was talking about before is when some (critical) >> resource needed for unittesting requires a very, very heavy >> initialization process. I'll employ the most recent example (hope it >> doesn't look like too much biased, it's just to illustrate the whole >> picture ;o) which is unittests for a framework like Trac . In that >> case it is critical to have a Trac environment, a ready-to-use DB and >> backend, initialize the plugins cache by loading relevant plugins, run >> the actions specified by each IEnvironmentSetup participant, sometimes >> a ready to use repository (if testing code depending on Trac VCS API) >> and more ... Just considering these cases someone could : >> >> - Create a fake environment used as a stub >> - But having a single global environment is not a good idea because >> it would be very difficult to run multiple (independent) tests >> concurrently (e.g. test multiple Trac plugins concurrently in a dedica= >> ted >> CI environment). So an environment has to be started for every >> test run and be as isolated as possible from other similar >> stub environments >> - The DB and backend can be replaced by using in-memory SQLite >> connection >> - Plugins cache and loading is mandatory as well running the actions >> specified by each IEnvironmentSetup participant >> - VCS can be mocked, but if it's needed it has to be initialized as well >> >> And all this is needed to run *ANY* test of *ANY* kind (that includes >> unittests ;o) . I hope that, up to this point, you all are convinced > > This doesn't sound very unit-testy, really. It sounds like you are > operating at a rather high level (closer to integration testing). > As someone else said, I don't see anything wrong with using unittest > as a basis for doing that myself, but I don't think your example is a > clear example of wanting a setup and teardown that is executed once per > TestCase for tests that are more obviously what everyone would consider > "unit" tests. > Well, probably this is OT here but I follow in order to clarify what I am saying. I am not integrating talking about integration tests, but in general, yes they are unittests, but for Trac plugins (i.e. it is possible that others tests won't need all this ;o) . For example let's consider TracRpc plugin. Let's say you are gonna implement an RPC handler that retrieves the ticket summary provided it's ID (pretty simple method indeed) . In that case you need - Implement IRPCHandler interface (in order to extend RPC system ;o) - Query ticket data Let's say you will only test that second part (which is the functional part without any objections ;o). In that case you'll still need a Trac environment, you'll need to setup the DB connection inside of it , and all that just to perform the query . In general, in such cases (e.g. DB access, but there are others ;o), almost everything needs a Trac environment and therefore, at least part of what I mentioned before ;o) > So, having the connection to the database set up once at TestCase start, > and closed at TestCase end, would make the most sense. Currently there's > no way I know of to do that, so I open and close the database for every > unittest. Fortunately it's an sqlite database, so the run time penalty > for doing that isn't prohibitive. > I really cannot see the difference between this and what I mentioned before since one of the things that's needed is to create a connexion just once for each test run, but (guess-what !) the connection needs to be set for the environment itself (i.e. trac.env.db ) so first the chicken, then the egg ;o) PS: BTW, The situation you mention is almost the classic example ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: PEP 391 - Please Vote! - http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsu
Re: [Python-Dev] Python 2.6.5
On Wed, 10 Feb 2010 13:57:31 +0200, anatoly techtonik wrote: > On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou wrote: > > > > Besides, as Barry said, classifying a bug as blocker is also a good way > > to attract some attention on it. Other classifications, even "critical", > > don't have the same effect. > > Unfortunately, not many people have privilege to change bug properties > to attract attention to the issues. For example, this patch - > http://bugs.python.org/issue7582 is ready to be committed, it is > trivial, not a release blocker, but would be nice be released. How to > make it evident if nobody except committers is able to add any > keywords to the issue? I suspect that even committers do not receive > this privilege automatically. FYI, committers do (or at least should) have full privileges on the tracker. Other people can also get full privileges on the tracker without being committers, generally by participating helpfully in issue review and issue triage. We give out tracker privileges more easily than commit privileges, but we don't give them out willy nilly. So the concern someone expressed about issues getting set to release blocker "just" to attract attention isn't an issue in practice, it seems to me. If a committer or triage person sets an issue to release blocker it should mean that they think the release manager should make a decision about that issue before the next release. That decision may well be that it shouldn't be a blocker. I think that the logic here is that it is all well and good if the release manager has the time to review all critical issues pre-release, but since they may not, those with tracker privs can help sort through the clutter by marking as release blockers those issues that the release manager (and others who are helping out) really *should* think about before the release goes out the door. I think that's what Barry was asking for when he said "feel free to mark things as release blockers". Of course there should be far fewer things getting set to release blocker for a maintenance release than for a new release even under this approach, and Martin's criteria are the ones that should be used by the release manager when deciding whether to *leave* an issue marked as a release blocker. But this is just my perception of the process, and I'm willing to work with whatever framework the community and release manager wants :) Anatoly, if you want particular issues to get attention, start reviewing issues on the tracker and helping move them along by commenting, and if your work is helpful you'll get noticed and offered tracker privs and be able to help even more. Related to this is the offer that Martin made and I have seconded: if someone wants attention paid to a particular issue, review five others and let Martin and/or I know and we'll review the issue you care about. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.5
> If a committer or triage > person sets an issue to release blocker it should mean that they think > the release manager should make a decision about that issue before the > next release. That decision may well be that it shouldn't be a blocker. I think it's (slightly) worse. For the release manager to override the triage, he has to study and understand the issue and then make the decision. In the past, that *did* cause delays in releases (though not in bug fix releases). So committers should be *fairly* conservative in declaring stuff release-critical. The release manager's time is too precious. > I think that the logic here is that it is all well and good if the release > manager has the time to review all critical issues pre-release, but since > they may not, those with tracker privs can help sort through the clutter > by marking as release blockers those issues that the release manager (and > others who are helping out) really *should* think about before the release > goes out the door. I think that's what Barry was asking for when he said > "feel free to mark things as release blockers". That would require that Barry actually *can* judge the issue at hand. In the specific case, I would expect that Barry would defer the specifics of the Windows issue to Windows experts, and then listen to what they say. I'm personally split whether the proposed patch is correct (i.e. whether asctime really *can* be implemented in a cross-platform manner; any definite ruling on that would be welcome). In the past, we had rather taken approaches like disabling runtime assertions "locally"; not sure whether such approaches would work for asctime as well. In any case, I feel that the issue is not security-critical at all. People just don't pass out-of-range values to asctime, but instead typically pass the result of gmtime/localtime, which will not cause any problems. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
