[Python-Dev] Maintaining old releases
>> Because there won't typically be sufficient testing and release >> infrastructure to allow arbitrary bug fixes to be committed on the >> branch. The buildbots are turned off, and nobody tests the release >> candidate, no Windows binaries are provided - thus, chances are very >> high that a bug fix release for some very old branch will be *worse* >> than the previous release, rather than better. > > Second, I don't think this is true. People using those patch > level releases will test and report bugs if they are introduced > by such backports. They might be using releases, but they are *not* using the subversion maintenance branches. Do you know anybody who regularly checks out the 2.4 maintenance branch and tests it? So at best, people will only report bugs *after* the release was made, meaning that there is a realistic chance that the release itself breaks things. As for using the releases themselves: there have been 80462 downloads of 2.4.5 since it was released in March, as compared to 517325 downloads of the 2.5.2 MSI in July alone. So I'm skeptical that many people do actually use the 2.4.5 release. > Besides, developers backporting such changes are diligent enough > to test their changes - they will usually have a reason for applying > the extra effort to backport. My problem is that this backporting is not systematic. It's arbitrary whether patches get backported or not. Part of the problem is that it is/was also unclear whether there ever will be another release made out of 2.4. When 2.4.4 was released, Anthony announced, in http://mail.python.org/pipermail/python-dev/2006-October/069326.html "This will be the last planned release in the Python 2.4 series" So anybody committing to the 2.4 branch after that should have expected that the patches will never get released. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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-committers] next beta
On Tue, Aug 12, 2008 at 4:21 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > First, I'd like to know why this discussion is happening on > the committers list. > > Python-dev is the right list for these things. I've adjusted the > CC accordingly. > > On 2008-08-12 20:44, Martin v. Löwis wrote: > > I am planning to offer a single file patch for 2.3 and 2.4. As far as > one more 2.5 release, I don't think there's going to be many changes > to the 2.5 branch between now and 2.6/3.0 final - although if there > is, we'll obviously have to do another release. I would like to establish a tradition where, after some final bug fix release (e.g. for 2.5), further "mere" bug fixes are banned from the maintenance branch (and I did revert several bug fixes from the 2.4 branch). >>> >>> I'm not sure I agree with this policy. Can you elaborate on /why/ you >>> want this? >> >> Because there won't typically be sufficient testing and release >> infrastructure to allow arbitrary bug fixes to be committed on the >> branch. The buildbots are turned off, and nobody tests the release >> candidate, no Windows binaries are provided - thus, chances are very >> high that a bug fix release for some very old branch will be *worse* >> than the previous release, rather than better. > > Second, I don't think this is true. People using those patch > level releases will test and report bugs if they are introduced > by such backports. > > Besides, developers backporting such changes are diligent enough > to test their changes - they will usually have a reason for applying > the extra effort to backport. But then it's too late! If there's a regression in 2.5.3 we'd have to issue a brown bag release 2.5.4. That would be more work for the release managers and frankly we don't have enough release manager hours as it is. So the argument that bugs will still get reported doesn't add up to much. The point is to avoid introducing bugs in the first place. > I don't see any advantage in undoing already tested and committed > patches to an older branch. > > Note that Python 2.4 is still widely used out there. As an > example, all the Zope and Plone installations run Python 2.4 and > will continue to do so for quite a while. And they do so because they want stability. I agree with the release managers that we should only issue security fixes for these platforms. Anything else adds the risk of breakage, i.e. instability. > And there's a reason for this slow uptake of Python 2.5: as more > and more servers run 64-bit OSes, the Py_ssize_t changes cause > serious trouble with Python C extensions that were not updated > by their authors. I'm not sure what that has to do with anything. The older releases have *worse* support for 64-bit platforms! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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-committers] next beta
First, I'd like to know why this discussion is happening on the committers list. Python-dev is the right list for these things. I've adjusted the CC accordingly. On 2008-08-12 20:44, Martin v. Löwis wrote: I am planning to offer a single file patch for 2.3 and 2.4. As far as one more 2.5 release, I don't think there's going to be many changes to the 2.5 branch between now and 2.6/3.0 final - although if there is, we'll obviously have to do another release. I would like to establish a tradition where, after some final bug fix release (e.g. for 2.5), further "mere" bug fixes are banned from the maintenance branch (and I did revert several bug fixes from the 2.4 branch). I'm not sure I agree with this policy. Can you elaborate on /why/ you want this? Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be *worse* than the previous release, rather than better. Second, I don't think this is true. People using those patch level releases will test and report bugs if they are introduced by such backports. Besides, developers backporting such changes are diligent enough to test their changes - they will usually have a reason for applying the extra effort to backport. I don't see any advantage in undoing already tested and committed patches to an older branch. Note that Python 2.4 is still widely used out there. As an example, all the Zope and Plone installations run Python 2.4 and will continue to do so for quite a while. And there's a reason for this slow uptake of Python 2.5: as more and more servers run 64-bit OSes, the Py_ssize_t changes cause serious trouble with Python C extensions that were not updated by their authors. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why duplicate output lines in verbose tests?
On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen <[EMAIL PROTECTED]> wrote: >> Is it using fork()? Threads? > > No on fork(), yes on threads. Hmm... I don't believe that io.py is thread-safe. :-( -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why duplicate output lines in verbose tests?
> Is it using fork()? Threads? No on fork(), yes on threads. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why duplicate output lines in verbose tests?
Is it using fork()? Threads?
On Tue, Aug 12, 2008 at 10:01 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Every so often, running the SSL test suite in verbose mode, I get
> something like this:
>
> server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256)
> server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256)
>
> That is, duplicate output lines. Any idea why that is? They're all
> written with something like:
>
> if support.verbose:
> sys.stdout.write(" some message\n")
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] why duplicate output lines in verbose tests?
Every so often, running the SSL test suite in verbose mode, I get
something like this:
server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256)
server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256)
That is, duplicate output lines. Any idea why that is? They're all
written with something like:
if support.verbose:
sys.stdout.write(" some message\n")
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Need 2 python developers in Dallas TX
On Tue, Aug 12, 2008, Bhavani wrote: > > I am looking to replace 2 Python developers for my client in Dallas > TX. This is a full time position and due to teh challenge in finding > Python Developers, my client is willing to be open on his salary > requirement and will offer relocation assistance as well plus > benefits. Please email resumes to [EMAIL PROTECTED] python-dev is the wrong place to advertise for jobs. Please see http://www.python.org/community/jobs/ -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Need 2 python developers in Dallas TX
Hello: I am looking to replace 2 Python developers for my client in Dallas TX. This is a full time position and due to teh challenge in finding Python Developers, my client is willing to be open on his salary requirement and will offer relocation assistance as well plus benefits. Please email resumes to [EMAIL PROTECTED] Regards, Bhavani ___ Python-Dev mailing list Python-Dev@python.org 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 Suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 12, 2008, at 11:13 AM, C. Titus Brown wrote: I'll forward this idea on to testing-in-python: http://lists.idyll.org/listinfo/testing-in-python where there was another bikeshed discussion about testing, a few weeks ago. That might be a good place to continue this discussion, at least until/if unittest-ng is created. Thanks Titus. I'm subscribing to that list now, but I fear the bikeshed. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKGrOHEjvBPtnXfVAQLFyQP+K9C71PfVLI1JxsfnZQKfDEi7FtRLN6GT W+DZOr/WnC6sDpSFF3xwfehNCDgu8GkW8zVcDQS2pbMW606RCXV8kvpmjL0Iuov8 rex0rhU16KPBAS1cgkf/dZQWUUy31OFzWTSSegtMw0T5EgOnbWWe2N3Tx2QKxGuv XBCjpcz4ofg= =Jwgr -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org 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 Suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 12, 2008, at 11:12 AM, Jean-Paul Calderone wrote: A SIG might be a good idea. There's also already the "testing in python" list, too: http://lists.idyll.org/listinfo/testing-in-python A lot of this discussion would be appropriate there. Ah, thanks for the pointer. If there's a good existing list that people want to keep, let's just raise its profile and point people there. I'm happy to create a SIG though if that's what people want. /me-subscribes-now-ly y'rs, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKGq1HEjvBPtnXfVAQIxygP+JrmWqbKDKDLWIPRK4QuPREZWEI35JHa7 CnDhXlcfayp/L0ZflO/7Vzeb5Q7gbOQR0pVR/YX0cjPZhcOm0XiyrTOSV8zJbbA4 XAMnR0vGqEgL9UgTb6K3XPt6fZT+72zhHomcqbALP/CBivwSkwEVNPas6/Ng2Dog P5Uigi7tsp0= =GypB -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org 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 Suggestions
On Tue, Aug 12, 2008 at 11:05:57AM -0400, Barry Warsaw wrote: -> -BEGIN PGP SIGNED MESSAGE- -> Hash: SHA1 -> -> On Aug 12, 2008, at 10:30 AM, Sebastian Rittau wrote: -> -> >[I just saw the other post about unit testing, while I was writing -> >this. -> >A strange conincidence.] -> -> Indeed. I've played around (again) recently with both nose and -> py.test, so I'd like to make a meta comment. -> -> I would really like to see some of the people who are interested in -> Python unit testing to get together and work on an updated testing -> framework that incorporates the best ideas from all the existing -> frameworks. I'd like to see good integration with setuptools, both -> for running the tests and for packaging. I'd like to see good doctest -> support, with the ability to hook in setups and teardowns. I'd like -> to see some of useful things like layers taken from zope.testing. -> -> This doesn't belong on python-dev, and probably not on python-ideas -> either, but I'd be willing to start a testing SIG on python.org if -> others are interested in getting together for this purpose. The goal -> should be to produce something like a unittest-ng, distribute it via -> the Cheeseshop, and gather consensus around it for possible inclusion -> in Python 2.7/3.1. Hi, Barry, I'll forward this idea on to testing-in-python: http://lists.idyll.org/listinfo/testing-in-python where there was another bikeshed discussion about testing, a few weeks ago. That might be a good place to continue this discussion, at least until/if unittest-ng is created. Sebastian, there was a long discussion on Python-Dev two or three weeks ago (you can't miss it in the July archives, I'd bet). You should read that IMO. cheers, --titus -- C. Titus Brown, [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org 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 Suggestions
On Tue, 12 Aug 2008 11:05:57 -0400, Barry Warsaw <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 12, 2008, at 10:30 AM, Sebastian Rittau wrote: [I just saw the other post about unit testing, while I was writing this. A strange conincidence.] Indeed. I've played around (again) recently with both nose and py.test, so I'd like to make a meta comment. I would really like to see some of the people who are interested in Python unit testing to get together and work on an updated testing framework that incorporates the best ideas from all the existing frameworks. I'd like to see good integration with setuptools, both for running the tests and for packaging. I'd like to see good doctest support, with the ability to hook in setups and teardowns. I'd like to see some of useful things like layers taken from zope.testing. This doesn't belong on python-dev, and probably not on python-ideas either, but I'd be willing to start a testing SIG on python.org if others are interested in getting together for this purpose. The goal should be to produce something like a unittest-ng, distribute it via the Cheeseshop, and gather consensus around it for possible inclusion in Python 2.7/3.1. A SIG might be a good idea. There's also already the "testing in python" list, too: http://lists.idyll.org/listinfo/testing-in-python A lot of this discussion would be appropriate there. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org 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 Suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 12, 2008, at 10:30 AM, Sebastian Rittau wrote: [I just saw the other post about unit testing, while I was writing this. A strange conincidence.] Indeed. I've played around (again) recently with both nose and py.test, so I'd like to make a meta comment. I would really like to see some of the people who are interested in Python unit testing to get together and work on an updated testing framework that incorporates the best ideas from all the existing frameworks. I'd like to see good integration with setuptools, both for running the tests and for packaging. I'd like to see good doctest support, with the ability to hook in setups and teardowns. I'd like to see some of useful things like layers taken from zope.testing. This doesn't belong on python-dev, and probably not on python-ideas either, but I'd be willing to start a testing SIG on python.org if others are interested in getting together for this purpose. The goal should be to produce something like a unittest-ng, distribute it via the Cheeseshop, and gather consensus around it for possible inclusion in Python 2.7/3.1. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKGm1XEjvBPtnXfVAQIEjgP+LsA8VpX62cnLzNgGv1jTLk7yhIvyKjEP nYgLOb1506FXnOUuXpPrqSS6ZOkr5Evt7jvkbSdIqbdLG3fpHYGFpt/KA0CHDdsE QuumBO5WenrFhB6yEoQoIa+oKg1McYYQfIFSVg+5owBi+Vo5vTZ7JaZyR43MUJon LbGqnMXRlqg= =sF2p -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unittest Suggestions
[I just saw the other post about unit testing, while I was writing this.
A strange conincidence.]
Hello,
since this is the first time I post to this list, I'd like to introduce
myself briefly. As you can see my name is Sebastian. I am working as a
software developer both as a professional and as a hobbyist. During the
years I've used many programming languages, but in the last few years
I've fallen in love with Python. (Blame Martin v. Löwis for that - I
started using Python after participating in a seminar held by him at
university.)
I'd like to propose a few changes to the unittest module. These changes
are supposed to ease usage, enable future changes and enhancements, and
bring unittest more in line with other modern xUnit variants (such as
JUnit 4 and NUnit). I have implemented most of those changes in a custom
library that hacks around the current unittest behaviour. I've published
the relevant package at [1]. All proposed changes are (mostly) backward
compatible.
Change unittest into a package
--
Currently unittest is a module. Changing it into a package would enable
us to separate concerns and move code out into separate modules. For
example the unittest.asserts proposal below requires this change. If a
mocking framework would be included in the Python standard library at
some point, it could go into unittest.mock etc.
@test, @before, and @after decorators
-
Currently unittest uses "magic" names starting with "test_" for detecting
the test methods in a test case class. Following the "explicit is better
than implicit" guideline, I propose to add a @test decorator to
explicitly mark test methods:
class MyTest(TestCase):
@test
def attributes(self):
"""Do stuff."""
I've been bitten in the past by naming methods test_xyz that were not
supposed to be called by the test runner. For now those methods still
need to be recognized, since they are widely used. But enabling (and
recommending) an alternative is a first step.
The decorator syntax makes is possible to introduce alternative
decorators as well, like @disabled_test. In the example package I
included a @performance_test decorator that takes a time argument where
the test fails if it takes more than a given amount of time.
Similarily I recommend to introduce @before and @after decorators to
supplement the setUp and tearDown methods. The decorators were named
after the decorators in JUnit 4, although I wonder whether @setup and
@teardown would be a better name. @before and @after methods are called
in any order, but @before methods in a super class are guaranteed to be
called before @before methods in a derived class, while it's vice versa
with @after methods. Introducing these has the added benefit of being
able to get rid of the mixedCase setUp and tearDown methods in my own
code.
unittest.asserts
Currently all assertions reside as methods on the TestCase class. This
means that all testing functions, including utility functions, need to be
on a TestCase-derived class. This seems wrong to me, especially since it
combines different concerns on a class: Testing the functionality of a
SUT, running a test suite, and providing test functions. This proposal
will not try to separate the first two concerns, but only the third one.
In the long term I think it's worthwhile to make tests work on any
class, not only on classes derived from TestCase, but as I said, this is
not part of this proposal.
JUnit 4 moved the assertions to a static class in a separate module. In
Python I'd propose to use functions in a separate module. A typical test
suite would then look like this:
from unittest import TestCase
from unittest.asserts import *
class FooTest(TestCase):
"""Tests for the Foo class."""
@before
def setup(self):
self._sut = create_an_object_to_test()
@test
def construct__some_attribute(self):
assert_equals("foobar", self._sut.some_attribute)
...
Again, as a side effect this removes inconsistent naming (mixedCase and
three different version of each test) from my tests. There is one
regression, though. Currently it's possible to change the assertion
exception (which defaults to AssertionError) by setting an attribute of
the TestCase instance. I am not sure how relevant that is, though. I've
never used this feature myself, not even when testing the unittest
module and its extensions, and this approach wouldn't work anyway, if
you use classes with utility assertions etc.
Anyway, I am happy about any comments.
- Sebastian
[1] http://www.rittau.biz/~srittau/unittest, though I will move it to
http://www.rittau.org/python/unittest, once I'm home.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An OO API for doctest / unittest integration...
You need to bring this sort of thing up in python-ideas before here,
first of all. Also, there isnt a strong case for including a module
that is only used by one project somewhere. Promote it on its own,
outside of this other project. Let other people use it and get
feedback from real use. When its popular, then it has a case for
inclusion.
What does it do that we cant already do without it? Just a "A novel
object-oriented API" isn't enough and your argument about downplay of
unittest for "lacking object-orientation" is a bit weak. It is what
works and people have problems with unittest but claims that just
vaguely talk about something being "OO enough" are almost always to be
skeptical about.
On Tue, Aug 12, 2008 at 9:08 AM, Olemis Lang <[EMAIL PROTECTED]> wrote:
> Hello... this is my first post to this list and...
>
> I would like to introduce myself by proposing a module for inclusion
> (hopefully in a "near future") among the standard libraries (modules)
> offered by Python (of course the idea is to present it here, promote
> the debate and if "we all like it", well... distribute it together
> with Python). I will be as concise as possible all the way through
> this message so as to avoid writing a long speech (and therefore a
> lengthy message). Further details can be found in an article published
> "a few months ago" [1].
>
> The module (its name... dutest) has the same goals considered to
> develop the unittest API provided by doctest since Python 2.4.
> However it includes other important features which make the
> difference. Some of them are the following:
>
> * A novel object-oriented API programmers can use in order to
>retrieve test cases out of interactive sessions in the form
>doctest examples. In other words, novel test loaders find and
>put test cases together, just like unittest test loaders do.
>Nowadays the unittest API included in doctest offers the functions
>DocFileSuite and DocTestSuite for this purpose, therefore lacking
>in object orientation.
>
> * The match made for different doctest examples during a doctest run
>is stored separately by instances of TestResult. Nowadays
>the unittest API included in doctest stores the whole doctest
>report at once into test results. This has some "drawbacks".
>Firstly, it is difficult to know what is wrong during the test
>(since to kinds of reports are intermingled). Besides several
>summaries can be found throughout test reports. When building test
>analysis tools, this also means that further parsing should be
>done so as to discover the descriptions of individual failures ...
>(further and more detailed analysis and explanations can be found
>in the aforementioned article [1])
>
> * A few more features...
>
> The module is actually employed for testing the pyOOP package
> (under development by the FLiOOPS project [2]). You can simply
> download dutest [3] and try it out, or you can also check out the
> trunk [4] doing something like
>
> $ svn co https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk .
>
> install the package doing something like
>
> $ setup.py install
> $ setup.py clean
>
> Optionally (if you like to see a much more real test report) you
> can also download the modules ipdbc [5], PyDBC [6], and
> PyContracts [7], and install them.
>
> Next, run pyOOP test suite from the Python interpreter doing something
> like
>
> {{{
> #!python
>
> try:
>from oop.test import check_oopdbc
> except ImportWarning:
>from oop.test import check_oopdbc
>
> oop.test.test_oopdbc.TESTLOG_FILE = '/path/to/log/file'
>
> check_oopdbc()
> }}}
>
> and "see" the output report (e.g. $ vi /path/to/log/file).
>
> Finally, any bug or bizarre behavior you find, please submit it to the
> bug tracking system of the FLiOOPS project [8]. We will fix it "as
> soon as we can". If you have any suggestion or need an additional
> feature, please submit a feature request to the FLiOOPs project [9]...
> and/or share it with us here in python-dev... ;) as well as any
> comments about the whole thing.
>
> I hope you like it :)
>
>
>
> [1] O. Lang, "Doctest and unittest… now they'll live happily forever"
>(2008) The Python Papers, vol. 3, no. 1, pp 38:51, ISSN 1834-3147.
>
> [2] FLiOOPS project home page
> (https://flioops.sourceforge.net)
>
> [3] Download page of module dutest
> (https://sourceforge.net/project/showfiles.php?group_id=220287&abmode=1)
>
> [4] pyOOP SVN trunk
> (https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk)
>
> [5] Yet another invariant/pre-/postcondition design-by-contract
> support module,
> Dmitry Dvoinikov
> (http://www.targeted.org/python/recipes/ipdbc.py)
>
> [6] PyDBC -- Design by Contract for Python 2.2+,
> Daniel Arbuckle
> (http://www.nongnu.org/pydbc/)
>
> [7] Contracts for Python (PEP 316),
> Terence Way
> (http://www.wayforward.net/pycontract/)
>
> [8] Bug tracking system of the
[Python-Dev] An OO API for doctest / unittest integration...
Hello... this is my first post to this list and...
I would like to introduce myself by proposing a module for inclusion
(hopefully in a "near future") among the standard libraries (modules)
offered by Python (of course the idea is to present it here, promote
the debate and if "we all like it", well... distribute it together
with Python). I will be as concise as possible all the way through
this message so as to avoid writing a long speech (and therefore a
lengthy message). Further details can be found in an article published
"a few months ago" [1].
The module (its name... dutest) has the same goals considered to
develop the unittest API provided by doctest since Python 2.4.
However it includes other important features which make the
difference. Some of them are the following:
* A novel object-oriented API programmers can use in order to
retrieve test cases out of interactive sessions in the form
doctest examples. In other words, novel test loaders find and
put test cases together, just like unittest test loaders do.
Nowadays the unittest API included in doctest offers the functions
DocFileSuite and DocTestSuite for this purpose, therefore lacking
in object orientation.
* The match made for different doctest examples during a doctest run
is stored separately by instances of TestResult. Nowadays
the unittest API included in doctest stores the whole doctest
report at once into test results. This has some "drawbacks".
Firstly, it is difficult to know what is wrong during the test
(since to kinds of reports are intermingled). Besides several
summaries can be found throughout test reports. When building test
analysis tools, this also means that further parsing should be
done so as to discover the descriptions of individual failures ...
(further and more detailed analysis and explanations can be found
in the aforementioned article [1])
* A few more features...
The module is actually employed for testing the pyOOP package
(under development by the FLiOOPS project [2]). You can simply
download dutest [3] and try it out, or you can also check out the
trunk [4] doing something like
$ svn co https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk .
install the package doing something like
$ setup.py install
$ setup.py clean
Optionally (if you like to see a much more real test report) you
can also download the modules ipdbc [5], PyDBC [6], and
PyContracts [7], and install them.
Next, run pyOOP test suite from the Python interpreter doing something
like
{{{
#!python
try:
from oop.test import check_oopdbc
except ImportWarning:
from oop.test import check_oopdbc
oop.test.test_oopdbc.TESTLOG_FILE = '/path/to/log/file'
check_oopdbc()
}}}
and "see" the output report (e.g. $ vi /path/to/log/file).
Finally, any bug or bizarre behavior you find, please submit it to the
bug tracking system of the FLiOOPS project [8]. We will fix it "as
soon as we can". If you have any suggestion or need an additional
feature, please submit a feature request to the FLiOOPs project [9]...
and/or share it with us here in python-dev... ;) as well as any
comments about the whole thing.
I hope you like it :)
[1] O. Lang, "Doctest and unittest… now they'll live happily forever"
(2008) The Python Papers, vol. 3, no. 1, pp 38:51, ISSN 1834-3147.
[2] FLiOOPS project home page
(https://flioops.sourceforge.net)
[3] Download page of module dutest
(https://sourceforge.net/project/showfiles.php?group_id=220287&abmode=1)
[4] pyOOP SVN trunk
(https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk)
[5] Yet another invariant/pre-/postcondition design-by-contract
support module,
Dmitry Dvoinikov
(http://www.targeted.org/python/recipes/ipdbc.py)
[6] PyDBC -- Design by Contract for Python 2.2+,
Daniel Arbuckle
(http://www.nongnu.org/pydbc/)
[7] Contracts for Python (PEP 316),
Terence Way
(http://www.wayforward.net/pycontract/)
[8] Bug tracking system of the FLiOOPS project
(https://sourceforge.net/tracker/admin/?atid=1049023&group_id=220287)
[9] Feature Request tracker system of the FLiOOPS project
(https://sourceforge.net/tracker/admin/?atid=1049026&group_id=220287)
[10] Send patches to the FLiOOPS project
(https://sourceforge.net/tracker/admin/?atid=1049025&group_id=220287)
--
Regards,
Olemis.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
