Re: [Python-Dev] Executing zipfiles and directories (was Re: PyCon Keynote)
On approximately 1/27/2010 1:08 AM, came the following characters from the keyboard of Glenn Linderman: Without reference to distutils, it seems the pieces are: 1) a way to decide what to include in the package 2) code that knows where to put what is included, on one or more platforms 3) the process to create the ZIP file that includes 1 & 2, and call it an appropriate name.py 3 looks easy, once 1 & 2 are figured out. distutils might provide the foundation for 1. 2 sounds like something a distutils application might create. I'm not sure that distutils is in the business of building installer programs, my understanding is that it is in the business of providing a standard way of recording and interpreting bills of materials and maybe dependencies, but that is based only on reading discussions here, not reading documentation. I haven't had a chance to read all the module documentation since coming to python. 3 was rather easy, and has come in handy for me, as it turned out: see http://code.activestate.com/recipes/577042/ -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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 wrote: > 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. There are actually a few folks with dev privileges on the tracker that don't have commit rights. They do a good job helping to kick things in the right direction (there are a few bugs on my list that wouldn't be there if the triage people hadn't added me to the nosy list... now I just need to actually do something about them all...) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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
Martin v. Löwis wrote: >> 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. When I've kicked issues in the RM's direction for a decision, I've generally tried to make sure my last comment makes it clear exactly what decision I'm asking them to make. If I didn't want their opinion on some aspect of the issue I would just reject it, postpone it or commit it myself :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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
Michael Foord wrote: > 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). +1 on fixing this in a way that doesn't break third-party tests :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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
Michael Foord wrote: > I'm not sure what response I expect from this email, and neither option > will be implemented without further discussion - possibly at the PyCon > sprints - but I thought I would make it clear what the possible > directions are. I'll repeat what I said in the python-ideas thread [1]: with the advent of PEP 343 and context managers, I see any further extension of the JUnit inspired setUp/tearDown nomenclature as an undesirable direction for Python to take. Instead, I believe unittest should be adjusted to allow appropriate definition of context managers that take effect at the level of the test module, test class and each individual test. For example, given the following method definitions in unittest.TestCase for backwards compatibility: def __enter__(self): self.setUp() def __exit__(self, *args): self.tearDown() The test framework might promise to do the following for each test: with get_module_cm(test_instance): # However identified with get_class_cm(test_instance): # However identified with test_instance: # ** test_instance.test_method() It would then be up to the design of the module and class context manager instances to cache any desired common state. Further design work would also be needed on the underlying API for identifying the module and class context managers given only the test instance to work with. The get_*_cm mechanisms would return a no-op CM if there was no specific CM defined for the supplied TestCase. Cheers, Nick. [1] http://mail.python.org/pipermail/python-ideas/2010-January/006758.html -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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 11/02/2010 12:30, Nick Coghlan wrote: Michael Foord wrote: I'm not sure what response I expect from this email, and neither option will be implemented without further discussion - possibly at the PyCon sprints - but I thought I would make it clear what the possible directions are. I'll repeat what I said in the python-ideas thread [1]: with the advent of PEP 343 and context managers, I see any further extension of the JUnit inspired setUp/tearDown nomenclature as an undesirable direction for Python to take. Instead, I believe unittest should be adjusted to allow appropriate definition of context managers that take effect at the level of the test module, test class and each individual test. For example, given the following method definitions in unittest.TestCase for backwards compatibility: def __enter__(self): self.setUp() def __exit__(self, *args): self.tearDown() The test framework might promise to do the following for each test: with get_module_cm(test_instance): # However identified with get_class_cm(test_instance): # However identified with test_instance: # ** test_instance.test_method() Well that is *effectively* how they would work (the semantics) but I don't see how that would fit with the design of unittest to make them work *specifically* like that - especially not if we are to remain compatible with existing unittest extensions. If you can come up with a concrete proposal of how to do this then I'm happy to listen. I'm not saying it is impossible, but it isn't immediately obvious. I don't see any advantage of just using context managers for the sake of it and definitely not at the cost of backwards incompatibility. Michael It would then be up to the design of the module and class context manager instances to cache any desired common state. Further design work would also be needed on the underlying API for identifying the module and class context managers given only the test instance to work with. The get_*_cm mechanisms would return a no-op CM if there was no specific CM defined for the supplied TestCase. Cheers, Nick. [1] http://mail.python.org/pipermail/python-ideas/2010-January/006758.html -- 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] unittest: shortDescription, _TextTestResult and other issues
On 11/02/2010 12:13, Nick Coghlan wrote: Michael Foord wrote: 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). +1 on fixing this in a way that doesn't break third-party tests :) It is done. The slight disadvantage is that overriding shortDescription on your own TestCase no longer removes the test name from being added to the short description. On the other hand if you do override shortDescription you don't have to add the test name yourself, and using a custom TestResult (overriding getDescription) is much easier now that the TextTestRunner takes a resultclass argument in the constructor. All the best, Michael Cheers, Nick. -- 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] PEP 3146: Merge Unladen Swallow into CPython
Snippet from: http://codereview.appspot.com/186247/diff2/5014:8003/7002 *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is slower than Unladen Swallow on non-numerical workloads. PyPy only supports 32-bit x86 code generation. It has poor support for CPython extension modules, making migration for large applications prohibitively expensive. That part at the very least has some sort of personal opinion "prohibitively", while the other part is not completely true "slower than US on non-numerical workloads". Fancy providing a proof for that? I'm well aware that there are benchmarks on which PyPy is slower than CPython or US, however, I would like a bit more weighted opinion in the PEP. Cheers, fijal ___ 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 Thu, Feb 11, 2010 at 7:41 AM, Michael Foord wrote: > On 11/02/2010 12:30, Nick Coghlan wrote: >> >> Michael Foord wrote: >> >>> >>> I'm not sure what response I expect from this email, and neither option >>> will be implemented without further discussion - possibly at the PyCon >>> sprints - but I thought I would make it clear what the possible >>> directions are. >>> >> >> I'll repeat what I said in the python-ideas thread [1]: with the advent >> of PEP 343 and context managers, I see any further extension of the >> JUnit inspired setUp/tearDown nomenclature as an undesirable direction >> for Python to take. >> >> Instead, I believe unittest should be adjusted to allow appropriate >> definition of context managers that take effect at the level of the test >> module, test class and each individual test. >> >> For example, given the following method definitions in unittest.TestCase >> for backwards compatibility: >> >> def __enter__(self): >> self.setUp() >> >> def __exit__(self, *args): >> self.tearDown() >> >> The test framework might promise to do the following for each test: >> >> with get_module_cm(test_instance): # However identified >> with get_class_cm(test_instance): # However identified >> with test_instance: # ** >> test_instance.test_method() >> > What Nick pointed out is the right direction (IMHO), and the one I had in mind since I realized that unittest extensibility is the key feature that needs to be implemented . I even wanted to start a project using this particular architecture to make PyUnit extensible. It's too bad (for me) that I don't have time at all, to move forward an just do it . :( I need days with 38 hrs !!! (at least) :$ > Well that is *effectively* how they would work (the semantics) but I don't > see how that would fit with the design of unittest to make them work > *specifically* like that - especially not if we are to remain compatible > with existing unittest extensions. > AFAICS (so not sure especially since there's nothing done to criticize ;o) is that backwards compatibility is not the main stopper ... > If you can come up with a concrete proposal of how to do this then I'm happy > to listen. I'm not saying it is impossible, but it isn't immediately > obvious. I don't see any advantage of just using context managers for the > sake of it and definitely not at the cost of backwards incompatibility. > ... but since I have nothing I can show you , everything is still in my mind ... -- 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] setUpClass and setUpModule in unittest
On 02:41 pm, [email protected] wrote: On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord wrote: On 11/02/2010 12:30, Nick Coghlan wrote: Michael Foord wrote: I'm not sure what response I expect from this email, and neither option will be implemented without further discussion - possibly at the PyCon sprints - but I thought I would make it clear what the possible directions are. I'll repeat what I said in the python-ideas thread [1]: with the advent of PEP 343 and context managers, I see any further extension of the JUnit inspired setUp/tearDown nomenclature as an undesirable direction for Python to take. Instead, I believe unittest should be adjusted to allow appropriate definition of context managers that take effect at the level of the test module, test class and each individual test. For example, given the following method definitions in unittest.TestCase for backwards compatibility: � def __enter__(self): � � self.setUp() � def __exit__(self, *args): � � self.tearDown() The test framework might promise to do the following for each test: � with get_module_cm(test_instance): # However identified � � with get_class_cm(test_instance): # However identified � � � with test_instance: # ** � � � � test_instance.test_method() What Nick pointed out is the right direction (IMHO), and the one I had Why? Change for the sake of change is not a good thing. What are the advantages of switching to context managers for this? Perhaps the idea was more strongly justified in the python-ideas thread. Anyone have a link to that? in mind since I realized that unittest extensibility is the key feature that needs to be implemented . I even wanted to start a project using this particular architecture to make PyUnit extensible. What makes you think it isn't extensible now? Lots of people are extending it in lots of ways. Jean-Paul ___ 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 Thu, Feb 11, 2010 at 9:41 AM, Olemis Lang wrote: > On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord > wrote: >> On 11/02/2010 12:30, Nick Coghlan wrote: >>> >>> Michael Foord wrote: >>> I'm not sure what response I expect from this email, and neither option will be implemented without further discussion - possibly at the PyCon sprints - but I thought I would make it clear what the possible directions are. >>> >>> I'll repeat what I said in the python-ideas thread [1]: with the advent >>> of PEP 343 and context managers, I see any further extension of the >>> JUnit inspired setUp/tearDown nomenclature as an undesirable direction >>> for Python to take. >>> >>> Instead, I believe unittest should be adjusted to allow appropriate >>> definition of context managers that take effect at the level of the test >>> module, test class and each individual test. >>> >>> For example, given the following method definitions in unittest.TestCase >>> for backwards compatibility: >>> >>> def __enter__(self): >>> self.setUp() >>> >>> def __exit__(self, *args): >>> self.tearDown() >>> >>> The test framework might promise to do the following for each test: >>> >>> with get_module_cm(test_instance): # However identified >>> with get_class_cm(test_instance): # However identified >>> with test_instance: # ** >>> test_instance.test_method() >>> >> > > What Nick pointed out is the right direction (IMHO), and the one I had > in mind since I realized that unittest extensibility is the key > feature that needs to be implemented . I even wanted to start a > project using this particular architecture to make PyUnit extensible. > It's too bad (for me) that I don't have time at all, to move forward > an just do it . > > :( > > I need days with 38 hrs !!! (at least) > > :$ > >> Well that is *effectively* how they would work (the semantics) but I don't >> see how that would fit with the design of unittest to make them work >> *specifically* like that - especially not if we are to remain compatible >> with existing unittest extensions. >> > > AFAICS (so not sure especially since there's nothing done to criticize > ;o) is that backwards compatibility is not the main stopper ... > >> If you can come up with a concrete proposal of how to do this then I'm happy >> to listen. I'm not saying it is impossible, but it isn't immediately >> obvious. I don't see any advantage of just using context managers for the >> sake of it and definitely not at the cost of backwards incompatibility. >> > > ... but since I have nothing I can show you , everything is still in my mind > ... > The idea (at least the one in my head ;o) is based on the features recently introduced in JUnit 4.7, especially the @Rule ;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] setUpClass and setUpModule in unittest
On Thu, Feb 11, 2010 at 10:11 AM, Olemis Lang wrote: > On Thu, Feb 11, 2010 at 9:41 AM, Olemis Lang wrote: >> On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord >> wrote: >>> On 11/02/2010 12:30, Nick Coghlan wrote: Michael Foord wrote: > > I'm not sure what response I expect from this email, and neither option > will be implemented without further discussion - possibly at the PyCon > sprints - but I thought I would make it clear what the possible > directions are. > I'll repeat what I said in the python-ideas thread [1]: with the advent of PEP 343 and context managers, I see any further extension of the JUnit inspired setUp/tearDown nomenclature as an undesirable direction for Python to take. Instead, I believe unittest should be adjusted to allow appropriate definition of context managers that take effect at the level of the test module, test class and each individual test. For example, given the following method definitions in unittest.TestCase for backwards compatibility: def __enter__(self): self.setUp() def __exit__(self, *args): self.tearDown() The test framework might promise to do the following for each test: with get_module_cm(test_instance): # However identified with get_class_cm(test_instance): # However identified with test_instance: # ** test_instance.test_method() >>> >> >> What Nick pointed out is the right direction (IMHO), and the one I had >> in mind since I realized that unittest extensibility is the key >> feature that needs to be implemented . I even wanted to start a >> project using this particular architecture to make PyUnit extensible. >> It's too bad (for me) that I don't have time at all, to move forward >> an just do it . >> >> :( >> >> I need days with 38 hrs !!! (at least) >> >> :$ >> >>> Well that is *effectively* how they would work (the semantics) but I don't >>> see how that would fit with the design of unittest to make them work >>> *specifically* like that - especially not if we are to remain compatible >>> with existing unittest extensions. >>> >> >> AFAICS (so not sure especially since there's nothing done to criticize >> ;o) is that backwards compatibility is not the main stopper ... >> >>> If you can come up with a concrete proposal of how to do this then I'm happy >>> to listen. I'm not saying it is impossible, but it isn't immediately >>> obvious. I don't see any advantage of just using context managers for the >>> sake of it and definitely not at the cost of backwards incompatibility. >>> >> >> ... but since I have nothing I can show you , everything is still in my mind >> ... >> > > The idea (at least the one in my head ;o) is based on the features > recently introduced in JUnit 4.7, especially the @Rule > > ;o) > .. [1] Writing your own JUnit extensions using @Rule | JUnit.org (http://www.junit.org/node/580) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: setUpClass and setUpModule in unittest | Python | Dev - http://feedproxy.google.com/~r/TracGViz-full/~3/x18-60vceqg/806136 ___ 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 Thu, Feb 11, 2010 at 10:10 AM, wrote: > On 02:41 pm, [email protected] wrote: >> >> On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord >> wrote: >>> >>> On 11/02/2010 12:30, Nick Coghlan wrote: Michael Foord wrote: > > I'm not sure what response I expect from this email, and neither option > will be implemented without further discussion - possibly at the PyCon > sprints - but I thought I would make it clear what the possible > directions are. I'll repeat what I said in the python-ideas thread [1]: with the advent of PEP 343 and context managers, I see any further extension of the JUnit inspired setUp/tearDown nomenclature as an undesirable direction for Python to take. Instead, I believe unittest should be adjusted to allow appropriate definition of context managers that take effect at the level of the test module, test class and each individual test. For example, given the following method definitions in unittest.TestCase for backwards compatibility: def __enter__(self): self.setUp() def __exit__(self, *args): self.tearDown() The test framework might promise to do the following for each test: with get_module_cm(test_instance): # However identified with get_class_cm(test_instance): # However identified with test_instance: # ** test_instance.test_method() >>> >> >> What Nick pointed out is the right direction (IMHO), and the one I had > > Why? Change for the sake of change is not a good thing. What are the > advantages of switching to context managers for this? > > Perhaps the idea was more strongly justified in the python-ideas thread. > Anyone have a link to that? >> >> in mind since I realized that unittest extensibility is the key >> feature that needs to be implemented . I even wanted to start a >> project using this particular architecture to make PyUnit extensible. > > What makes you think it isn't extensible now? Lots of people are extending > it in lots of ways. > Nothing I want to spend my time on. Just consider what the authors of JUnit (and XUnit too) thought about JUnit<4.7, what they did in JUnit 4.7, and you'll save me a lot of time I don't have to explain it to you (/me not being rude /me have no time :-/ ) -- 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 10 Feb, 02:47 pm, [email protected] wrote: On Tue, Feb 9, 2010 at 6:15 PM, wrote: 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 ? Several reasons: - Over the many years the feature was available, we never found anyone actually benefiting significantly from it. It was mostly used where setUp/tearDown would have worked just as well. - There are many confusing corner cases related to ordering and error handling (particularly in the face of inheritance). Different users invariably have different expectations about how these things work, and there's no way to satisfy them all. One might say that this could apply to any feature, but... - People are exploring other solutions (such as testresources) which may provide better functionality more simply and don't need support deep in the loader/runner/reporter implementations. Jean-Paul ___ 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 11:46 PM, Martin v. Löwis wrote: >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. Yep, absolutely. >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. Unless other details come to light, I agree. This one isn't worth holding up the release for. -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] Python 2.6.5
On Feb 11, 2010, at 10:05 PM, Nick Coghlan wrote: >When I've kicked issues in the RM's direction for a decision, I've >generally tried to make sure my last comment makes it clear exactly what >decision I'm asking them to make. Yes, this is an *excellent* point! -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 Thu, 11 Feb 2010 12:41:37 +, Michael Foord
wrote:
> On 11/02/2010 12:30, Nick Coghlan wrote:
> > The test framework might promise to do the following for each test:
> >
> >with get_module_cm(test_instance): # However identified
> > with get_class_cm(test_instance): # However identified
> >with test_instance: # **
> > test_instance.test_method()
>
> Well that is *effectively* how they would work (the semantics) but I
> don't see how that would fit with the design of unittest to make them
> work *specifically* like that - especially not if we are to remain
> compatible with existing unittest extensions.
>
> If you can come up with a concrete proposal of how to do this then I'm
> happy to listen. I'm not saying it is impossible, but it isn't
> immediately obvious. I don't see any advantage of just using context
> managers for the sake of it and definitely not at the cost of backwards
> incompatibility.
I suspect that Nick is saying that it is worth doing for the sake of it,
as being more "Pythonic" in some sense.
That is, it seems to me that in a modern Python writing something like:
@contextlib.contextmanager
def foo_cm(testcase):
testcase.bar = some_costly_setup_function()
yield
testcase.bar.close()
@contextlib.contextmanager
def foo_test_cm(testcase):
testcase.baz = Mock(testcase.bar)
yield
@unittest.case_context(foo_cm)
@unittest.test_context(foo_test_cm)
class TestFoo(unittest.TestCase):
def test_bar:
foo = Foo(self.baz, testing=True)
self.assertTrue("Context managers are cool")
would be easier to write, be more maintainable, and be easier to
understand when reading the code than the equivalent setUp and tearDown
methods would be.
I'm not saying it would be easy to implement, and as you say backward
compatibility is a key concern.
--
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 11/02/2010 15:56, R. David Murray wrote:
On Thu, 11 Feb 2010 12:41:37 +, Michael Foord
wrote:
On 11/02/2010 12:30, Nick Coghlan wrote:
The test framework might promise to do the following for each test:
with get_module_cm(test_instance): # However identified
with get_class_cm(test_instance): # However identified
with test_instance: # **
test_instance.test_method()
Well that is *effectively* how they would work (the semantics) but I
don't see how that would fit with the design of unittest to make them
work *specifically* like that - especially not if we are to remain
compatible with existing unittest extensions.
If you can come up with a concrete proposal of how to do this then I'm
happy to listen. I'm not saying it is impossible, but it isn't
immediately obvious. I don't see any advantage of just using context
managers for the sake of it and definitely not at the cost of backwards
incompatibility.
I suspect that Nick is saying that it is worth doing for the sake of it,
as being more "Pythonic" in some sense.
That is, it seems to me that in a modern Python writing something like:
@contextlib.contextmanager
def foo_cm(testcase):
testcase.bar = some_costly_setup_function()
yield
testcase.bar.close()
@contextlib.contextmanager
def foo_test_cm(testcase):
testcase.baz = Mock(testcase.bar)
yield
@unittest.case_context(foo_cm)
@unittest.test_context(foo_test_cm)
class TestFoo(unittest.TestCase):
def test_bar:
foo = Foo(self.baz, testing=True)
self.assertTrue("Context managers are cool")
would be easier to write, be more maintainable, and be easier to
understand when reading the code than the equivalent setUp and tearDown
methods would be.
I'm not saying it would be easy to implement, and as you say backward
compatibility is a key concern.
This is quite different to what Nick *specifically* suggested. It also
doesn't suggest a general approach that would easily allow for
setUpModule as well.
*However*, I am *hoping* to be able to incorporate some or all of Test
Resources as a general solution (with simple recipes for the setUpClass
and setUpModule cases) - at which point this particular discussion will
become moot.
All the best,
Michael Foord
--
R. David Murray www.bitdance.com
--
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] setUpClass and setUpModule in unittest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olemis Lang wrote: > 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) Just as a point of reference: zope.testing[1] has a "layer" feature which is used to support this usecase: a layer is a class namedd as an attribute of a testcase, e.g.: class FunctionalLayer: @classmethod def setUp(klass): """ Do some expesnive shared setup. """ @classmethod def tearDown(klass): """ Undo the expensive setup. """ class MyTest(unittest.TestCase): layer = FunctionalLayer The zope.testing testrunner groups testcase classes together by layer: each layer's setUp is called, then the testcases for that layer are run, then the layer's tearDown is called. Other features: - - Layer classes can define per-testcase-method 'testSetUp' and 'testTearDown' methods. - - Layers can be composed via inheritance, and don't need to call base layers' methods directly: the testrunner does that for them. These features has been in heavy use for about 3 1/2 years with a lot of success. [1] http://pypi.python.org/pypi/zope.testing/ Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt0LeYACgkQ+gerLs4ltQ57WgCdFTzc1OHocXj/WTLShP62Q1bx vSAAnAqE/9+o1tZAaSLzlXfxaoRGTiuf =O/b2 -END 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 04:18 pm, [email protected] wrote: Just as a point of reference: zope.testing[1] has a "layer" feature which is used to support this usecase: a layer is a class namedd as an attribute of a testcase, e.g.: class FunctionalLayer: @classmethod def setUp(klass): """ Do some expesnive shared setup. """ @classmethod def tearDown(klass): """ Undo the expensive setup. """ class MyTest(unittest.TestCase): layer = FunctionalLayer The zope.testing testrunner groups testcase classes together by layer: each layer's setUp is called, then the testcases for that layer are run, then the layer's tearDown is called. Other features: - - Layer classes can define per-testcase-method 'testSetUp' and 'testTearDown' methods. - - Layers can be composed via inheritance, and don't need to call base layers' methods directly: the testrunner does that for them. These features has been in heavy use for about 3 1/2 years with a lot of success. [1] http://pypi.python.org/pypi/zope.testing/ On the other hand: http://code.mumak.net/2009/09/layers-are-terrible.html I've never used layers myself, so I won't personally weigh in for or against. Jean-Paul ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [email protected] wrote: > On 04:18 pm, [email protected] wrote: >> Just as a point of reference: zope.testing[1] has a "layer" feature >> which is used to support this usecase: a layer is a class namedd as an >> attribute of a testcase, e.g.: >> >> class FunctionalLayer: >> @classmethod >> def setUp(klass): >> """ Do some expesnive shared setup. >> """ >> @classmethod >> def tearDown(klass): >> """ Undo the expensive setup. >> """ >> >> class MyTest(unittest.TestCase): >> layer = FunctionalLayer >> >> The zope.testing testrunner groups testcase classes together by layer: >> each layer's setUp is called, then the testcases for that layer are >> run, >> then the layer's tearDown is called. >> >> Other features: >> >> - - Layer classes can define per-testcase-method 'testSetUp' and >> 'testTearDown' methods. >> >> - - Layers can be composed via inheritance, and don't need to call base >> layers' methods directly: the testrunner does that for them. >> >> These features has been in heavy use for about 3 1/2 years with a lot >> of >> success. >> >> >> [1] http://pypi.python.org/pypi/zope.testing/ > > On the other hand: > > http://code.mumak.net/2009/09/layers-are-terrible.html > > I've never used layers myself, so I won't personally weigh in for or > against. I don't know the author of that post as a core Zope developer: the fact is that using inheritance to manage the layers works just fine for Zope's thousands of functional tests. As for his objections: if you don't want the superclass methods called, then don't make your layer inherit from it (why else would you?). Sharing setup across test methods is the whole point of layers, or of the other mechanisms being discussed here: while I agree that such tests aren't "unit tests" in the classic sense, they do have their place. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt0OoAACgkQ+gerLs4ltQ5YSACeLzR+LfkafGB3GLWMgMPvdiPc 8nEAoKuudwJMznZiyrmJD1SHcOkYw3cr =6VG8 -END 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 Thu, Feb 11, 2010 at 11:18 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Olemis Lang wrote: >> 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) > > Just as a point of reference: zope.testing[1] has a "layer" feature > which is used to support this usecase: a layer is a class namedd as an > attribute of a testcase, e.g.: > > class FunctionalLayer: > @classmethod > def setUp(klass): > """ Do some expesnive shared setup. > """ > @classmethod > def tearDown(klass): > """ Undo the expensive setup. > """ > > class MyTest(unittest.TestCase): > layer = FunctionalLayer > > The zope.testing testrunner groups testcase classes together by layer: > each layer's setUp is called, then the testcases for that layer are run, > then the layer's tearDown is called. > > Other features: > > - - Layer classes can define per-testcase-method 'testSetUp' and > 'testTearDown' methods. > > - - Layers can be composed via inheritance, and don't need to call base > layers' methods directly: the testrunner does that for them. > > These features has been in heavy use for about 3 1/2 years with a lot of > success. > I really like the style and the possibility to control the scope of ( setUp | tearDown ) . That's something I'd really consider to be included in the API ... and if it was accompanied or integrated to something like the @Rule in the backend to make it look like an extension and thus provide «standar mechanism(s)» to get other similar features done outside stdlib too, well, much better ;o) I have to start using Zope ! Damn, I'm wasting my few most happy years ! PS: I confess that I didn't follow the thread @ Py-Ideas. I associated Nick comment to the @Rule because, in JUnit, this is implemented using something similar to Aspect Oriented Programming (something like before and after hooks ;o), and in that case the Pythonic (and IMHO more «explicit») translation could be context managers . Perhaps I misunderstood something in previous messages . -- 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:42 AM, Michael Foord wrote: > 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. ;-) Hi Michael, I have skimmed this thread (hence this reply to the first rather than the last message), but in general I am baffled by the hostility of testing framework developers towards their users. The arguments against class- and module-level seUp/tearDown functions seems to be inspired by religion or ideology more than by the zen of Python. What happened to Practicality Beats Purity? The potential for abuse in and of itself should not be an argument against a feature; it must always be weighed against the advantages. The argument that a unittest framework shouldn't be "abused" for regression tests (or integration tests, or whatever) is also bizarre to my mind. Surely if a testing framework applies to multiple kinds of testing that's a good thing, not something to be frowned upon? There are several alternative testing frameworks available outside the standard library. The provide useful competition with the stlib's unittest and doctest modules, and useful inspiration for potential new features. They also, by and large, evolve much faster than a stdlib module ever could, and including anyone of these in the stdlib might well be the death of it (just as unittest has evolved much slower since it was included). But unittest *is* still evolving, and there is no reason not to keep adding features along the lines of your module/class setUp/tearDown proposal (or extra assertions like assertListEqual, which I am happy to see has been added). On the other hand, I think we should be careful to extend unittest in a consistent way. I shuddered at earlier proposals (on python-ideas) to name the new functions (variations of) set_up and tear_down "to conform with PEP 8" (this would actually have violated that PEP, which explicitly prefers local consistency over global consistency). I also think that using a with-statement or a decorator to indicate the scope of setUp/tearDown operations flies in the face of the existing "style" of the unittest module (um, package, I know :-), which is based on defining setUp and tearDown methods with specific semantics. Regarding the objection that setUp/tearDown for classes would run into issues with subclassing, I propose to let the standard semantics of subclasses do their job. Thus a subclass that overrides setUpClass or tearDownClass is responsible for calling the base class's setUpClass and tearDownClass (and the TestCase base class should provide empty versions of both). The testrunner should only call setUpClass and tearDownClass for classes that have at least one test that is selected. Yes, this would mean that if a base class has a test method and a setUpClass (and tearDownClass) method and a subclass also has a test method and overrides setUpClass (and/or tearDown), the base class's setUpClass and tearDown may be called twice. What's the big deal? If setUpClass and tearDownClass are written properly they should support this. If this behavior is undesired in a particular case, maybe what was really meant were module-level setUp and tearDown, or the class structure should be rearranged. Anyway, Michael, thanks for getting this started -- I support your attempts to improve the unittest package and am writing in the hope that the discussion will soon converge and patches whipped up. -- --Guido van Rossum (python.org/~guido) ___ 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 Thu, Feb 11, 2010 at 1:11 PM, Guido van Rossum wrote: > On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord > wrote: >> 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. ;-) > > But unittest *is* still evolving, as well as the XUnit paradigm as a whole, especially considering the recent work committed to and released by JUnit ;o) . > > On the other hand, I think we should be careful to extend unittest in > a consistent way. +1 . IMO that's a key indicator of the success of anything related to its evolution . > Regarding the objection that setUp/tearDown for classes would run into > issues with subclassing, I propose to let the standard semantics of > subclasses do their job. Thus a subclass that overrides setUpClass or > tearDownClass is responsible for calling the base class's setUpClass > and tearDownClass (and the TestCase base class should provide empty > versions of both). The testrunner should only call setUpClass and > tearDownClass for classes that have at least one test that is > selected. > +1 Considering zope.testing layers proposal, it seems that subclassing of layers works different, isn't it ? -- 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
Le Thu, 11 Feb 2010 10:56:32 -0500, R. David Murray a écrit :
>
> @unittest.case_context(foo_cm)
> @unittest.test_context(foo_test_cm)
> class TestFoo(unittest.TestCase):
>
> def test_bar:
> foo = Foo(self.baz, testing=True)
> self.assertTrue("Context managers are cool")
>
> would be easier to write, be more maintainable, and be easier to
> understand when reading the code than the equivalent setUp and tearDown
> methods would be.
I don't think it would be seriously easier to write, more maintainable or
easier to understand. There's nothing complicated or obscure in setUp and
tearDown methods (the only annoying thing being PEP8 non-compliance).
As a matter of fact, nose has a "with_setup()" decorator which allows to
avoid writing setUp/tearDown methods. But in my experience it's more
annoying to use because:
- you have to add the decorator explicitly (setUp/tearDown is always
invoked)
- you have to create your own recipient for local state (setUp/tearDown
can simply use the TestCase instance), or use global variables which
is ugly.
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] Python 2.6.5
Le Thu, 11 Feb 2010 10:36:22 -0500, Barry Warsaw a écrit : > > Unless other details come to light, I agree. This one isn't worth > holding up the release for. Ok, since everyone seems to agree on this, I've downgraded the priority of the issue. Thanks for an insightful discussion :-) cheers 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] setUpClass and setUpModule in unittest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olemis Lang wrote: > On Thu, Feb 11, 2010 at 1:11 PM, Guido van Rossum wrote: >> Regarding the objection that setUp/tearDown for classes would run into >> issues with subclassing, I propose to let the standard semantics of >> subclasses do their job. Thus a subclass that overrides setUpClass or >> tearDownClass is responsible for calling the base class's setUpClass >> and tearDownClass (and the TestCase base class should provide empty >> versions of both). The testrunner should only call setUpClass and >> tearDownClass for classes that have at least one test that is >> selected. >> > > +1 > > Considering zope.testing layers proposal, it seems that subclassing of > layers works different, isn't it ? Hmm, I wasn't making a proposal that the unittest module adopt zope.testing's layers model: I was just trying to point out that another model did exist and was being used successfully. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt0WcUACgkQ+gerLs4ltQ6CgACfb9kQ6vpu6BwOJLBOLDnHnTil dZMAnjdkdT/5RQXGIWFXGuUgnV8rQSuI =ExUu -END 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
Hi Guido, On Thu, Feb 11, 2010 at 7:11 PM, Guido van Rossum wrote: > On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord > wrote: >> 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. ;-) > > Hi Michael, > > I have skimmed this thread (hence this reply to the first rather than > the last message), but in general I am baffled by the hostility of > testing framework developers towards their users. The arguments > against class- and module-level seUp/tearDown functions seems to be > inspired by religion or ideology more than by the zen of Python. What > happened to Practicality Beats Purity? Hostility against users? I have not heart that feedback from my users yet - or am i missing some meaning of your words? > The potential for abuse in and of itself should not be an argument > against a feature; it must always be weighed against the advantages. sure. > The argument that a unittest framework shouldn't be "abused" for > regression tests (or integration tests, or whatever) is also bizarre > to my mind. Surely if a testing framework applies to multiple kinds of > testing that's a good thing, not something to be frowned upon? If an approach has known limitations it's also good to point them out. Also ok to disregard them and still consider something useful enough. > There are several alternative testing frameworks available outside the > standard library. The provide useful competition with the stlib's > unittest and doctest modules, and useful inspiration for potential new > features. They also, by and large, evolve much faster than a stdlib > module ever could, and including anyone of these in the stdlib might > well be the death of it (just as unittest has evolved much slower > since it was included). Fully agreed :) > But unittest *is* still evolving, and there is no reason not to keep > adding features along the lines of your module/class setUp/tearDown > proposal (or extra assertions like assertListEqual, which I am happy > to see has been added). > > On the other hand, I think we should be careful to extend unittest in > a consistent way. I shuddered at earlier proposals (on python-ideas) > to name the new functions (variations of) set_up and tear_down "to > conform with PEP 8" (this would actually have violated that PEP, which > explicitly prefers local consistency over global consistency). If that was me you refer to - i followed PEP8 5 years ago when introducing setup_class/module and i still stand by it, it was supposed to be a more pythonic alternative and i consider PEP8 as part of that. But i agree - introducing it to std-unittest now makes not much sense due to local consistency reasons. I appreciate Michael's effort to help advance testing - we have a good private discussion currently btw - and i am happy to collaborate with him on future issues, setupClass or not :) cheers, holger ___ 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 Thu, 11 Feb 2010 16:08:54 +, Michael Foord
wrote:
> On 11/02/2010 15:56, R. David Murray wrote:
> > On Thu, 11 Feb 2010 12:41:37 +, Michael
> > Foord wrote:
> >> On 11/02/2010 12:30, Nick Coghlan wrote:
> >>> The test framework might promise to do the following for each test:
> >>>
> >>> with get_module_cm(test_instance): # However identified
> >>> with get_class_cm(test_instance): # However identified
> >>> with test_instance: # **
> >>> test_instance.test_method()
> >>>
> >
> > @contextlib.contextmanager
> > def foo_cm(testcase):
> > testcase.bar = some_costly_setup_function()
> > yield
> > testcase.bar.close()
> >
> > @contextlib.contextmanager
> > def foo_test_cm(testcase):
> > testcase.baz = Mock(testcase.bar)
> > yield
> >
> >
> > @unittest.case_context(foo_cm)
> > @unittest.test_context(foo_test_cm)
> > class TestFoo(unittest.TestCase):
> >
> > def test_bar:
> > foo = Foo(self.baz, testing=True)
> > self.assertTrue("Context managers are cool")
> >
> >
> This is quite different to what Nick *specifically* suggested. It also
> doesn't suggest a general approach that would easily allow for
> setUpModule as well.
I'm not sure how it is different. I thought I was indicating how to do
the context manager "discovery" that Nick punted on. (Except for module
level, which I didn't have a good idea for).
> *However*, I am *hoping* to be able to incorporate some or all of Test
> Resources as a general solution (with simple recipes for the setUpClass
> and setUpModule cases) - at which point this particular discussion will
> become moot.
Which pretty much makes my noddling above moot right now, because having
taken a quick look at testresources I think that's a much closer fit for
my use cases than class level setup/teardown. So I'm +1 for going the
testresources route rather than the setup/teardown route.
--
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 Thu, Feb 11, 2010 at 11:26 AM, Holger Krekel wrote: > Hi Guido, > > On Thu, Feb 11, 2010 at 7:11 PM, Guido van Rossum wrote: >> On Tue, Feb 9, 2010 at 8:42 AM, Michael Foord >> wrote: >>> 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. ;-) >> >> Hi Michael, >> >> I have skimmed this thread (hence this reply to the first rather than >> the last message), but in general I am baffled by the hostility of >> testing framework developers towards their users. The arguments >> against class- and module-level seUp/tearDown functions seems to be >> inspired by religion or ideology more than by the zen of Python. What >> happened to Practicality Beats Purity? > > Hostility against users? I have not heart that feedback from my users > yet - or am i missing some meaning of your words? Sorry for the sweeping generality. I was referring to one or more posts (I don't recall by whom) arguing against including class/module setup/teardown functionality based on it being against the notion of unittesting or something like that. I'm sorry, but the thread is too long for me to find the specific post. But I'm pretty sure I saw something like that. >> The potential for abuse in and of itself should not be an argument >> against a feature; it must always be weighed against the advantages. > > sure. > >> The argument that a unittest framework shouldn't be "abused" for >> regression tests (or integration tests, or whatever) is also bizarre >> to my mind. Surely if a testing framework applies to multiple kinds of >> testing that's a good thing, not something to be frowned upon? > > If an approach has known limitations it's also good to point them out. > Also ok to disregard them and still consider something useful enough. > >> There are several alternative testing frameworks available outside the >> standard library. The provide useful competition with the stlib's >> unittest and doctest modules, and useful inspiration for potential new >> features. They also, by and large, evolve much faster than a stdlib >> module ever could, and including anyone of these in the stdlib might >> well be the death of it (just as unittest has evolved much slower >> since it was included). > > Fully agreed :) > >> But unittest *is* still evolving, and there is no reason not to keep >> adding features along the lines of your module/class setUp/tearDown >> proposal (or extra assertions like assertListEqual, which I am happy >> to see has been added). > >> >> On the other hand, I think we should be careful to extend unittest in >> a consistent way. I shuddered at earlier proposals (on python-ideas) >> to name the new functions (variations of) set_up and tear_down "to >> conform with PEP 8" (this would actually have violated that PEP, which >> explicitly prefers local consistency over global consistency). > > If that was me you refer to - i followed PEP8 5 years ago when > introducing setup_class/module and i still stand by it, it was > supposed to be a more pythonic alternative and i consider PEP8 as part > of that. But i agree - introducing it to std-unittest now makes not > much sense due to local consistency reasons. Ok let's drop it then. > I appreciate Michael's effort to help advance testing - we have a good > private discussion currently btw - and i am happy to collaborate with > him on future issues, setupClass or not :) > > cheers, > holger > -- --Guido van Rossum (python.org/~guido) ___ 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
Michael Foord writes: > It is done. The slight disadvantage is that overriding > shortDescription on your own TestCase no longer removes the test name > from being added to the short description. That's a significant disadvantage; it can easily double the length of the reported description for a test case. Before: The Wodget should spangulate with the specified doohickey... ok After: test_zwickyblatt.MechakuchaWidget.test_spangulates_with_specified_doohickey: The Wodget should spangulate with the specified doohickey... ok (if I have the new description incorrect feel free to correct me, but I think the point is clear about adding the test name to the description). Reports that before would mostly stay within a standard 80-column terminal will now almost always be line-wrapping, making the output much harder to read. > On the other hand if you do override shortDescription you don't have > to add the test name yourself The problem isn't only with overridden shortDescription. The problem is the breakage in the existing behaviour of shortDescription, even in cases that never needed to override shortDescription. > and using a custom TestResult (overriding getDescription) is much > easier now that the TextTestRunner takes a resultclass argument in the > constructor. Again, it seems that adding this to the output is the job of the thing which does the reporting, *if* wanted. The (long!) name isn't part of the TestCase description, so shouldn't be bolted onto the TestResult description. -- \ Moriarty: “Forty thousand million billion dollars? That money | `\must be worth a fortune!” —The Goon Show, _The Sale of | _o__) Manhattan_ | Ben Finney ___ 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
Guido van Rossum writes: > The potential for abuse in and of itself should not be an argument > against a feature; it must always be weighed against the advantages. It's both, surely? The potential for abuse of something is an argument against it; *and* that argument should be weighed against other arguments. Or, in other words: the potential for abuse of a feature is an argument that should not be discarded solely because there are advantages to that feature. > The argument that a unittest framework shouldn't be "abused" for > regression tests (or integration tests, or whatever) is also bizarre > to my mind. Surely if a testing framework applies to multiple kinds of > testing that's a good thing, not something to be frowned upon? To my mind, an API should take a stand on the “right” way to use it, rather than being a kitchen-sink of whatever ideas had any support. Doing something the right way should be easy, and doing something the wrong way should be awkward. This must be balanced, of course, with the principle that easy things should be easy and difficult things should be possible. But it doesn't necessarily conflict; we just need to take care that the easy and the right align well :-) > There are several alternative testing frameworks available outside the > standard library. The provide useful competition with the stlib's > unittest and doctest modules, and useful inspiration for potential new > features. They also, by and large, evolve much faster than a stdlib > module ever could, and including anyone of these in the stdlib might > well be the death of it (just as unittest has evolved much slower > since it was included). Right. This is an argument in favour of being assertive and parsimonious in the design of the standard-library ‘unittest’ API: this is the clear and obvious way to use this API, and if someone wants to do it a different way there are alternatives available. > But unittest *is* still evolving, and there is no reason not to keep > adding features along the lines of your module/class setUp/tearDown > proposal (or extra assertions like assertListEqual, which I am happy > to see has been added). That's a dismissal of the reasons that have been presented, without actually countering those reasons. > Anyway, Michael, thanks for getting this started -- I support your > attempts to improve the unittest package and am writing in the hope > that the discussion will soon converge and patches whipped up. Ditto. -- \ “I have had a perfectly wonderful evening, but this wasn't it.” | `\ —Groucho Marx | _o__) | Ben Finney ___ 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 2010-02-11 16:20 PM, Ben Finney wrote: Guido van Rossum writes: The argument that a unittest framework shouldn't be "abused" for regression tests (or integration tests, or whatever) is also bizarre to my mind. Surely if a testing framework applies to multiple kinds of testing that's a good thing, not something to be frowned upon? To my mind, an API should take a stand on the “right” way to use it, rather than being a kitchen-sink of whatever ideas had any support. Doing something the right way should be easy, and doing something the wrong way should be awkward. setUpClass and setUpModule are the "right" way to do many types of integration and functional tests. Integration and functional tests are vital tasks to perform, and unittest provides a good framework otherwise for implementing such tests. There are several alternative testing frameworks available outside the standard library. The provide useful competition with the stlib's unittest and doctest modules, and useful inspiration for potential new features. They also, by and large, evolve much faster than a stdlib module ever could, and including anyone of these in the stdlib might well be the death of it (just as unittest has evolved much slower since it was included). Right. This is an argument in favour of being assertive and parsimonious in the design of the standard-library ‘unittest’ API: this is the clear and obvious way to use this API, and if someone wants to do it a different way there are alternatives available. I would agree if the requirements for unit testing and integration/functional tests were so different. However, unittest provides most of the necessary infrastructure that is common to all of those kinds of testing. It's just that the latter kinds of tests also could use setUpClass/setUpModule. It would be a waste (and honestly kind of ridiculous) to force people to use a whole new framework (which would duplicate unittest in almost its entirety) for want of those two methods. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ 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 Fri, Feb 12, 2010 at 12:00 AM, Robert Kern wrote: > On 2010-02-11 16:20 PM, Ben Finney wrote: >> >> Guido van Rossum writes: > >>> The argument that a unittest framework shouldn't be "abused" for >>> regression tests (or integration tests, or whatever) is also bizarre >>> to my mind. Surely if a testing framework applies to multiple kinds of >>> testing that's a good thing, not something to be frowned upon? >> >> To my mind, an API should take a stand on the “right” way to use it, >> rather than being a kitchen-sink of whatever ideas had any support. >> Doing something the right way should be easy, and doing something the >> wrong way should be awkward. > > setUpClass and setUpModule are the "right" way to do many types of > integration and functional tests. Integration and functional tests are vital > tasks to perform, and unittest provides a good framework otherwise for > implementing such tests. Ben just expressed his opinion about API design and you claim some truth about testing in general. In my experience, integration and functional testing is a complex and evolving topic, usually requiring more from the tool or framework than classic unit-testing. To name a few issues: * creating tempdirs and files * setting up base environments * starting and stopping servers * mocking components * replaying individual tests * reacting to timeouts * handling asynchronicity * web-javascript integration support * configuring fixtures from config files * CI tool integration and multi-platform deployment * running variations of the same tests across different base configs * ... much much more It's true that you can go and extend unittest for that but a) unittest is just a tiny bit of what is involved for satisfying the needs b) what you are doing then is mostly using the fact that a setup function (or chain) is invoked and a test function is invoked and that python has some builtin modules for handling the above issues. And you are using Python - and Python is nice and (potentially) concise for writing tests, sure. That's not wholly the fault of the unittest module, though :) So. Doing fixtures via static encoding in class and module setup functions is a way to provide a generic framing for writing tests. The "right" way? In many cases and for the about 6 different people i interacted with (and on actual RL code) in the last 2 weeks it does not help incredibly much. There is experiences from other test tool authors indicating similar experiences. I will say that module/class can be helpful and you can do some useful things with it and thus it makes some sense to add it for std-unittest but claiming this is great and most of what you need for "many types" of functional testing is misleading and plays down the many good things you can do with Testing and Python. best, holger ___ 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 2010-02-11 17:57 PM, Holger Krekel wrote: On Fri, Feb 12, 2010 at 12:00 AM, Robert Kern wrote: On 2010-02-11 16:20 PM, Ben Finney wrote: Guido van Rossumwrites: The argument that a unittest framework shouldn't be "abused" for regression tests (or integration tests, or whatever) is also bizarre to my mind. Surely if a testing framework applies to multiple kinds of testing that's a good thing, not something to be frowned upon? To my mind, an API should take a stand on the “right” way to use it, rather than being a kitchen-sink of whatever ideas had any support. Doing something the right way should be easy, and doing something the wrong way should be awkward. setUpClass and setUpModule are the "right" way to do many types of integration and functional tests. Integration and functional tests are vital tasks to perform, and unittest provides a good framework otherwise for implementing such tests. Ben just expressed his opinion about API design and you claim some truth about testing in general. My first sentence was about API design. My second was justification that the use case is worth designing and API for. You can add implicit "in my opinion"s to just about anything I say, if you wish. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ 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 11/02/2010 22:03, Ben Finney wrote: Michael Foord writes: It is done. The slight disadvantage is that overriding shortDescription on your own TestCase no longer removes the test name from being added to the short description. That's a significant disadvantage; it can easily double the length of the reported description for a test case. Before: The Wodget should spangulate with the specified doohickey... ok After: test_zwickyblatt.MechakuchaWidget.test_spangulates_with_specified_doohickey: The Wodget should spangulate with the specified doohickey... ok There is a newline between the testname and the first line of the docstring. If there is no docstring behaviour is completely unchanged. This is how it was in the 2.7 codebase before I made the change and is unchanged. The only difference is that you don't lose this behaviour by overriding TestCase.shortDescription(). (if I have the new description incorrect feel free to correct me, but I think the point is clear about adding the test name to the description). Reports that before would mostly stay within a standard 80-column terminal will now almost always be line-wrapping, making the output much harder to read. On the other hand if you do override shortDescription you don't have to add the test name yourself The problem isn't only with overridden shortDescription. The problem is the breakage in the existing behaviour of shortDescription, even in cases that never needed to override shortDescription. shortDescription itself is now unchanged from Python 2.6. and using a custom TestResult (overriding getDescription) is much easier now that the TextTestRunner takes a resultclass argument in the constructor. Again, it seems that adding this to the output is the job of the thing which does the reporting, *if* wanted. The (long!) name isn't part of the TestCase description, so shouldn't be bolted onto the TestResult description. Well, it *is* the TextTestResult that does the reporting. Don't believe me - look at the code. Test results are reported (written to the output stream) by the TextTestResult. Actually my description above was slightly incorrect - it is only TextTestResult that has a getDescription method, so custom TestResult implementations that inherit directly from TestResult will now also have unchanged behavior from 2.6 in this regard. Michael -- 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] unittest: shortDescription, _TextTestResult and other issues
Michael Foord writes: > There is a newline between the testname and the first line of the > docstring. If there is no docstring behaviour is completely unchanged. […] > shortDescription itself is now unchanged from Python 2.6. Thanks, that completely addresses and satisfies my concerns about the test case reporting. Great work, Michael; not only in the coding, but especially in the communication about these changes. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney ___ 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
