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 th
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 doubl
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 a
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
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
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 ot
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
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 an
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:
> >>>
>
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 suppo
-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.
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
A
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")
>
>
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.
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 sha
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
exar...@twistedmatrix.com wrote:
> On 04:18 pm, tsea...@palladion.com 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,
On 04:18 pm, tsea...@palladion.com 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 som
-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
>>>
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 g
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 ident
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
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'
On 10 Feb, 02:47 pm, ole...@gmail.com 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 m
On Thu, Feb 11, 2010 at 10:10 AM, wrote:
> On 02:41 pm, ole...@gmail.com 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 neit
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
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 wit
On 02:41 pm, ole...@gmail.com 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
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 - bu
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, ma
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
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.
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 th
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
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 (sligh
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
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 pr
37 matches
Mail list logo
