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
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
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
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
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
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.
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
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 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
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 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 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 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 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 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 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 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 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
-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 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
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 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
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 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.
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")
>
>
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
-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.
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
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:
> >>>
>
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
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
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
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
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 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 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
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
37 matches
Mail list logo
