Tres Seaver wrote:
Ron Adam wrote:
Nick Coghlan wrote:
The essence of the function remains unchanged - you're still asserting
that a particular exception is raised. Returning the actual exception
object that was caught is merely a convenience that makes a lot of sense.
I'm not sure I unders
Please move all discussions of unittest frameworks to
[EMAIL PROTECTED] It is an interesting topic -- so interesting,
in fact, that exploring all the different ideas under discussion is
overwhelming the primary purpose of python-dev, which at this point is
to get the 2.6 and 3.0 releases into shape
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron Adam wrote:
>
> Nick Coghlan wrote:
>> The essence of the function remains unchanged - you're still asserting
>> that a particular exception is raised. Returning the actual exception
>> object that was caught is merely a convenience that makes
Nick Coghlan wrote:
Taking an existing function such as assertRaises and going "hey, we
aren't using the return value from this, wouldn't it be really
convenient if it told us the exact exception it actually caught?"
doesn't cause any problems for existing code, and makes it much easier
to
Ben Finney wrote:
The function name should say *all* that the function does, from the
perspective of the caller.
I have to disagree with that (and I think you'll find plenty of other
folks here will disagree as well). A good function names needs to have a
few characters:
- serve as a mnemonic
Guido van Rossum wrote:
On Wed, Jul 16, 2008 at 7:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
The result I'm trying to avoid by this is that of having the
externally visible behaviour of functions drift from the promise made
by their names. Either rename the function, or create a new one for
th
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> On Wed, Jul 16, 2008 at 7:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> > The result I'm trying to avoid by this is that of having the
> > externally visible behaviour of functions drift from the promise
> > made by their names. Either rename the f
On Wed, Jul 16, 2008 at 7:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> The result I'm trying to avoid by this is that of having the
> externally visible behaviour of functions drift from the promise made
> by their names. Either rename the function, or create a new one for
> the new functionality
Ben Finney <[EMAIL PROTECTED]> writes:
> You're proposing to give "assertRaises" a *new* meaning, without
> changing its name to "assertRaisesAndReturnExceptionIfRaises".
This might be misunderstood, so I'll make it clearer.
The name "assert raises" has a strong (and, per Guido, deliberate)
asso
Steve Holden <[EMAIL PROTECTED]> writes:
> Yes, but unless I misunderstand you, you don't regard a mass
> renaming of the module's functionality and removal of existing
> aliases as a change to the API.
You slightly misunderstand me. The above changes *are* a change to the
API, by definition. My
Ben Finney wrote:
[...]
>
> I hope that clarifies it. The name of a thing, in Python especially,
> is very important; in an API, even more so. If the behaviour of the
> function isn't matched by the name, it's a poorly chosen name, a
> poorly designed function, or both.
It doesn't really clarify
Ben Finney wrote:
Michael Foord <[EMAIL PROTECTED]> writes:
Collecting testcases from the filesystem is a pain. But actually
writing tests (including custom TestCases) using the unittest API is
fine. I find unittest straightforward and readable, I like it.
I don't understand a lot of the criti
Andrew Bennetts <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
> > Andrew Bennetts <[EMAIL PROTECTED]> writes:
> [...]
> > > How is returning None a feature?
> >
> > A test method having exactly one meaning is a feature. If it's
> > consistent across the API, the API retains a level of simplicit
I'd quote “Practicality beats purity”, but I'm not even sure if it
is purity that you have in mind.
From: "Ben Finney" <[EMAIL PROTECTED]>
Close: I'm interested in keeping camel's noses out of tents.
I have no idea what you mean or are trying to accomplish
(unless the camel's nose refers to c
On Jul 16, 2008, at 9:45 PM, Andrew Bennetts wrote:
I am proposing that it should have exactly one meaning. Callers
will be free to
ignore the return value if they don't need it, and will see zero
difference in
behaviour.
Sounds like adding a new method, catchException(...), that returns
Ben Finney wrote:
> Andrew Bennetts <[EMAIL PROTECTED]> writes:
[...]
> > How is returning None a feature?
>
> A test method having exactly one meaning is a feature. If it's
> consistent across the API, the API retains a level of simplicity.
Your reply makes no sense to me.
I am proposing that i
Andrew Bennetts <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
> > Andrew Bennetts <[EMAIL PROTECTED]> writes:
> >
> > > This one is easily solved by making assertRaises return the
> > > exception it caught.
> >
> > That breaks one simple feature of the unittest API: that all the
> > test metho
Ben Finney wrote:
> Andrew Bennetts <[EMAIL PROTECTED]> writes:
>
> > This one is easily solved by making assertRaises return the
> > exception it caught.
>
> That breaks one simple feature of the unittest API: that all the test
> methods will either raise a failure asertion, or return None.
How
Andrew Bennetts <[EMAIL PROTECTED]> writes:
> This one is easily solved by making assertRaises return the
> exception it caught.
That breaks one simple feature of the unittest API: that all the test
methods will either raise a failure asertion, or return None.
--
\ “In case you haven
Michael Foord wrote:
> Raymond Hettinger wrote:
[...]
>>
>> If some people want to proceed down the path of "useful additions",
>> I challenge them to think bigger. Give me some test methods that
>> improve my life. Don't give me thirty ways to spell something I can
>> already do.
>>
>
> I assert
Guido van Rossum wrote:
On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
From: "Michael Foord" <[EMAIL PROTECTED]>
assertIn / assertNotIn I use very regularly for collection membership
- self.assert_(func(x) in result_set)
+ self.assertIn(func(x), result_set)
Yawn
On Wed, Jul 16, 2008 at 3:52 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> For my part, I wanted the redundancies removed and the PEP 8
> conformance fixed as a precondition too *any* addition to the unittest
> API.
That seems an unproductive attitude towards backwards incompatibility.
I'm glad you
Michael Foord <[EMAIL PROTECTED]> writes:
> Collecting testcases from the filesystem is a pain. But actually
> writing tests (including custom TestCases) using the unittest API is
> fine. I find unittest straightforward and readable, I like it.
>
> I don't understand a lot of the criticism comes
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Having skimmed much material about proposed changes to the venerable
> unitest module, I'd like to set some boundaries. PEPs that don't
> follow the following rules are very unlikely to be accepted.
Thanks for giving the attention to this topic and
On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> If some people want to proceed down the path of "useful additions",
>>> I challenge them to think bigger. Give me some test methods that
>>> improve my life. Don't give me thirty ways to spell something I can
>>> al
On Wed, Jul 16, 2008 at 10:37:46PM +0100, Michael Foord wrote:
-> >test_sort2.py :
-> >
-> > def test_me():
-> >seq = [ 5, 4, 1, 3 2 ]
-> >seq.sort()
-> >assert seq == [1, 2, 3, 4, 5]
-> >
-> >The *only value* that unittest adds here is in the 'assertEqual'
-> >statement, which (I think
On 16/07/2008, at 18:24, Guido van Rossum wrote:
Think bigger! No fat APIs. Do something cool! Checkout the
dynamic test creation in test_decimal to see if it can be
generalized.
Give me some cool test runners. Maybe find a way to automatically
launch pdb or to dump the locals variables
C. Titus Brown schrieb:
Sorry for the second message, but... let's compare:
test_sort.py:
#! /usr/bin/env python
import unittest
class Test(unittest.TestCase):
def test_me(self):
seq = [ 5, 4, 1, 3, 2 ]
seq.sort()
self.assertEqual(seq, [1, 2, 3, 4, 5])
if __name__ == '__ma
C. Titus Brown wrote:
On Wed, Jul 16, 2008 at 02:15:29PM -0700, C. Titus Brown wrote:
-> At this point I might suggest taking a look at the nose and py.test
-> discovery rules and writing a simple test discovery system to find &
-> wrap 'test_' functions/classes and doctests in a unittest wrapper
On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> From: "Michael Foord" <[EMAIL PROTECTED]>
>> assertIn / assertNotIn I use very regularly for collection membership
>
> - self.assert_(func(x) in result_set)
> + self.assertIn(func(x), result_set)
>
> Yawn. The gain is
On Wed, Jul 16, 2008 at 02:15:29PM -0700, C. Titus Brown wrote:
-> At this point I might suggest taking a look at the nose and py.test
-> discovery rules and writing a simple test discovery system to find &
-> wrap 'test_' functions/classes and doctests in a unittest wrapper.
->
-> Many people use
C. Titus Brown wrote:
[snip..]
Paranthetically, wrt unittest, the world seems to be divided into two
kinds of people : those who find the current API uninspiring but ok, and
those who absolutely hate it. Has anyone said that they *love* the
current unittest API with all of its boilerplate? If n
On Wed, Jul 16, 2008 at 02:03:29PM -0700, Raymond Hettinger wrote:
-> - self.assert_(func(x) in result_set)
-> + self.assertIn(func(x), result_set)
->
-> Yawn. The gain is zero. Actually, it's negative because the second
-> doesn't read as nicely as the pure python expression.
People are propos
On Wed, Jul 16, 2008 at 1:03 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>> 2. Radical changes to the API are off the table. If a radically
>> different API is to be accepted, the road to such acceptance is not a
>> design-by-committee PEP, but adoption of a 3rd party mod
If some people want to proceed down the path of "useful additions",
I challenge them to think bigger. Give me some test methods that
improve my life. Don't give me thirty ways to spell something I can
already do.
From: "Michael Foord" <[EMAIL PROTECTED]>
I assert that... the following changes
Raymond Hettinger wrote:
From: "Michael Foord" <[EMAIL PROTECTED]>
I assume this doesn't rule out the addition of [some of..] the new
convenience test methods?
In Kent Beck's book on Test Driven Development, he complains that most
unittest implementations spawned from his original work have g
From: "Michael Foord" <[EMAIL PROTECTED]>
I assume this doesn't rule out the addition of [some of..] the new
convenience test methods?
In Kent Beck's book on Test Driven Development, he complains that most
unittest implementations spawned from his original work have grown far
too complicated
Guido van Rossum wrote:
Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.
1. The API is not going to be renamed to PEP-8 conformance. This
notwithstand
On Wed, Jul 16, 2008 at 2:57 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Having skimmed much material about proposed changes to the venerable
> unitest module, I'd like to set some boundaries. PEPs that don't
> follow the following rules are very unlikely to be accepted.
So basically, discus
Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.
1. The API is not going to be renamed to PEP-8 conformance. This
notwithstanding the purported outcome
40 matches
Mail list logo
